ARIN's own in-addr records don't satisfy the draft:

dig www.arin.net. +short
69.25.34.199
192.149.252.16
192.149.252.17
[EMAIL PROTECTED] dean]$ dig -x 192.149.252.16 +short
ww1.arin.net.
www.arin.net.
arin.net.
[EMAIL PROTECTED] dean]$ dig -x 192.149.252.17 +short
www.arin.net.
arin.net.
ww2.arin.net.
[EMAIL PROTECTED] dean]$ dig -x 69.25.34.199 +short
ashburn-199.arin.net.
host-34-199.arin.net.

They don't match. Indeed, there is no forward name "ashburn-199.arin.net".

"host-34-199.arin.net." is auto-generated. If all in-addr were so
auto-generated , there would be no point in having in-addr at all.

Often this auto-generation is done by the address registrant who received
the assignment to satisfy the zealots whose FTP or mail servers reject
connections. 

In-addr is a convenience function. It is not a "security" function.  The 
existance and "matching" of in-addr has no relationship to any of the 
commonly asserted claims by the anti-spammer zealots who insist on it:

They frequently make absurd claims such as:

1) matching in-addr means that email isn't spam.

2) matching in-addr means that address space isn't hijacked.

3) matching in-addr means that one can "trust" the name is who it claims 
to be.

One and Two above are just wrong. This is obvious to all but the zealots.

Number three is also wrong, as has been graphically proven over time.  
However, it is apparently not so obvious, as it was the false assumption
that made possible the BSD r-command exploits. This exploit is still
possible with some tcp-wrappers mis-configurations advocated by people on
this list.  Number Three also made possible (from roughly 1986 to 1993)  
anonymous relay abuse, whereby one could send anonymous email by faking or
removing the in-addr name. Sendmail relied on the correctness of the
in-addr. Indeed, this fault was made by our own chair, Rob Austein who
fell for number 3 in 1986, when he argued against including the IP address
in the Sendmail Received: header, believing wrongly that in-addr was
sufficent and if it wasn't "we should fix the silly net"

Haven't we learned our lesson already?

                --Dean


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


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

Reply via email to