On Oct 30, 2013, at 11:55 AM, Andrew Sullivan <asullivan@dyn.com> wrote:
As I think I've said before on this list, when we tried to get consensus on that claim in the DNSOP WG at the IETF, we couldn't. Indeed, we couldn't even get consensus on the much more bland statement, "Some people rely on the reverse, and you might want to take that into consideration when running your services."
It's taking all of my willpower to avoid an IETF rant. :) The "SHOULD" here is one way. A PTR record should point to a valid forward name that resolves to the same IP address. To quote RFC 1034, a PTR is "a pointer to another part of the domain name space". If the RHS of a PTR is not a valid domain name, that's just not true. But rather than some pedantic rant about standards there's a practical purpose here. Tools that receive IP addresses will generate names using reverse lookups, those names should then work. For instance if trace route gives a name, "ping <name>" should then work. But the opposite is not true. Many forward records may point to the same IP address, and there is no need for reverses to match. (in shorthand) 10.0.0.1 PTR webhosting.foo.com webhosting.foo.com A 10.0.0.1 www.sitea.com A 10.0.0.1 www.siteb.com A 10.0.0.1 www.sitec.com A 10.0.0.1 -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/