Reverse DNS RFCs and Recommendations

Wed Oct 30 17:36:03 UTC 2013

On Oct 30, 2013, at 11:55 AM, Andrew Sullivan <asullivan at 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 at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 793 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131030/1691f25b/attachment.sig>