On Oct 30, 2013, at 11:55 AM, Andrew Sullivan <asulli...@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 - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
signature.asc
Description: Message signed with OpenPGP using GPGMail
