Subject: [dnsop] INADDR draft feedback please

From: Daniel Senie <[email-masked]>
Date: Mon, 18 Oct 2004 16:50:43 -0400

I'm working toward submitting the -06 of this draft this week. My working 
copy is viewable via one of my web pages:

http://www.senie.com/dan/draft-ietf-dnsop-inaddr-required.txt

I believe I have captured all the comments I've received about the draft.

PLEASE NOTE: the boilerplate change that recently went into effect has not 
yet been applied, and it's what I'm going to work on next. I wanted to get 
the content updated and see if anyone had any more input, providing time 
for such review while I update the boilerplate. (In other words, please 
don't send me notes about the boilerplate being out of date!).

I look forward to any comments.

Dan
-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

   "September 11, 2001, already a day of immeasurable tragedy,
       cannot be the day liberty perished in this country."
                  -- 11th Circuit Court of Appeals 

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 Oct 2004 19:57:00 -0400 (EDT)

I thought this was dead. Is there truly a significant portion of this
working group that is interested in this? It seems to me to be only Rob
Austein, Dan Senie and perhaps a few others.

It appears to be written more ambiguously than the previous drafts.  
Count "Lack of clarity" as a new objection to this draft.  Other than
that, it appears to have no significant changes given the last discussion
of the subject.  This draft also has the following previously raised
problems:

* It still contains the incorrect and misleading statements regarding the
policies of ARIN.  ARIN policy does not require the use of INADDR. Indeed,
ARIN has been considering dropping INADDR altogether. According to Leslie,
it has discussed the issue with its lawyers, and it is not required to
provide any INADDR services, and can drop those services if it chooses. 
The draft uses an ambiguous paraphrase of ARIN's policy to create a 
misleading impression that INADDR is required.

* It still makes the invalid, incorrect, and misleading assertions
regarding the validity of DNS names.  The claim that "Some applications
attempt to use it as a part of a security strategy." is literally true,
but is a practice that should be strongly discouraged. This document seems
to justify this (bad) practice, and will therefore promote further bad
practice, counter to the goals of the IETF in promoting good practices.  
There is no category "Worst Common Practice".

* It still makes the incorrrect and misleading assertion that "This
document has no negative impact on security." when it has been shown by
numerous experiences that trusting INADDR to establish the validity of DNS
names is a serious and severe violation of security.  Encouraging bad 
security practices has a negative impact on security.

* It is still self-contradictory, and suggests that IN-ADDR is required in
the Introduction:  "This practice, while documented, has never been
documented as a requirement placed upon those who control address blocks.
This document fills this gap."  Many would read this as making IN-ADDR
required.

* Section 3, "Examples of impact of missing IN-ADDR" is just a list of bad
practices. Such bad practices need to be discouraged, both for security
reasons and because INADDR doesn't work in IPV6.  The comparable feature
in IPV6 is the hostinfo functionality. 

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 19 Oct 2004 10:41:54 +0200

On Mon, Oct 18, 2004 at 04:50:43PM -0400,
 Daniel Senie <[email-masked]> wrote 

> http://www.senie.com/dan/draft-ietf-dnsop-inaddr-required.txt

My opinion:

1) Too many sites wrongly use PTR checking without understand it. The
warnings in 4.2 and 5 are not enough. Mentions of use (like "anti-spam
fight") in 3 MUST be accompanied by a stronger warning that this test
is junk.

It is one thing to say that PTR should be deployed more. And another
to allow its current use which is, under the current state of
deployment, a bad idea.

2) Although the draft mentions the responsabilities of the RIR
(delegating .ARPA) and of the LIR (subdelegating), it fails to mention
that, presently, most ISP in the world do not delegate .ARPA. In
entire continents, like Africa, it is next to impossible to get an
.ARPA delegation.

Look at ns1.nic.af, the stealth primary name server of the TLD
".af". Its address, 65.162.19.242, comes from the World Bank which do
not even have a delegation from the upstream, Sprint. So, World Bank
cannot delegate it to the Afghan NIC. As a result, many sites stupidly
reject email from this afghani network.

IMO, this is the sort of abuse we should fight first. I suggest to
delete the draft and, instead, to write one I-D named "PTR checking
considered harmful".
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html