You have missed several issues, in my opinion. There are others, which I've pointed out, previously, including false and misleading "quotes" of the policies for other authorities. For example, ARIN does not
"require ISPs to maintain IN-ADDR for /16 or larger allocations. For smaller allocations, ARIN can provide IN-ADDR for /24 and shorter prefixes." This is a mistatement of ARIN's policy. ARIN doesn't provide IN-ADDR mappings for ANYONE. ARIN does not require ANYONE to provide IN-ADDR mapping. ARIN only provides delegation records to those who WISH TO use IN-ADDR. Let me say it again: ARIN doesn't require anyone to use IN-ADDR. Senie's assertion otherwise is flat out wrong. Furthermore, as I've reported here previously, I've spoken to ARIN about this, and ARIN has been considering not offering the Delegation function. It has gone so far as to research the issue with its attorneys, to find out whether it is required to provide this, and the attorneys indicated it was not so required. The draft also mentions the notion of "the proper deployment of in-addr". This notion is flawed and wrong. First, the forward+reverse check can't be performed 100% of the time, even if one wanted. The people clamoring for this draft assert (wrongly) that a matching forward/reverse configuration is always possible. It isn't. For example, 1) it is benefiicial to have reverse pointing to a preferred name for which the forward address has a preferred address. These don't overlap. 2) One might have a large number of forward names with the same address, for which there is no single reverse name, and all the names are too large for a DNS packet (virtual web hosts) 3) An address registry may not offer reverse delegation. 4) etc. Section 3 is a rogues gallery of bad behavior by APPLICATIONS: Section 3. Examples of impact of missing IN-ADDR These are some examples of problems that may be introduced by reliance on IN-ADDR. The examples given are not "problems caused by missing IN-ADDR", but rather ABUSE of IN-ADDR. The DNS Operations group is to give guidance to the application writers NOT TO USE IN-ADDR THAT WAY. I can't make that any clearer. Senie's draft suggests that the "problem" is caused by a missing IN-ADDR, and this is wrong. More inline: > On Sun, 20 Feb 2005, Daniel Senie wrote: > >> By recommending applications avoid using IN-ADDR as a security > >> mechanism this document points out that this practice, despite its > >> use by many applications, is an ineffective form of security. > >> Applications should use better mechanisms of authentication. > >> > >> > >> ==> this could probably be beefed up better, see e.g. > >> draft-ietf-dnsop-ipv6-dns-issues-10.txt. In particular, IMHO it should be > >> noted that: > >> 1) simple reverse lookup offers no security at all > >> 2) reverse+forward check is not a true form of security, but could be > >> useful > >> combined with other forms of checking > > > > reverse+forward checks is NOT security. You're verifying that someone has > > access to zone files, nothing more. BTW, this is not quite correct. Its really much worse than that. DNS can be spoofed (and cache poised) in only 65000 packets). You have _not_ proven access to zone files. This check proves nothing, beyond a poisoned cached. > > So if the DNS servers (forward and > > reverse) for a CIDR block are within that block, and the block is hijacked > > (this is happening), then the hijacker can make you believe he's who you > > think he is, and all the DNS checks for reverse+forward verify it. Use a > > security mechanism if you want security. I don't agree there's any place > > for > > advocating reverse+forward in this document. > > But yet, it _is_ a form of security. Err, no. It is a security _Vulnerability_. Its a perception of security (as you so demonstrate) that creates an security exposure. This forum should not be advocating the use of a security vulnerability. > For example, lots of people have tcp wrappers configuration in their > SSHD, requiring that connection attempts come from host.example.com, > .example.net or whatever (forward+reverse check). This is especially > useful when the server is at example.net, but has a couple of pinholes > to the world. This is an example of what should _NOT_ be done. Ever. But you are correct that people do that. That practice needs to be _DISCOURAGED_, not encouraged. > In addition to that, there is a public key security or password > authentication. > > That kind of additional check _does_ increase the overall security of > the system significantly (if you compare to a situation where you > would not have any tcp wrappers checks). The flaw is that you assume that you cannot use tcp-wrappers checks if you don't have reverse. That is not true. > So, I think the document is > disconnected from the reality in its attempt to please the most > stringent security communities. I think the author is disconnected from reality if they think that the document attempts to please even the most un-stringent security community. It is a security _HARM_. > The key point is that forward+reverse DNS check is not a sufficient > security mechanism on its own, but almost always needs something more > -- and that folks which use it need to understand its weaknesses in > designing the additional security measures. "On its own"? Its no check at all. Period. Its a vulnerability, not a check. -- 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
