Reverse DNS RFCs and Recommendations

Andrew Sullivan asullivan at dyn.com
Wed Oct 30 18:12:17 UTC 2013


On Wed, Oct 30, 2013 at 12:36:03PM -0500, Leo Bicknell wrote:
> The "SHOULD" here is one way.

Of course, there is no SHOULD anywhere.  RFC 1034 is from the era
before RFC 2119, and there really isn't any guidance on the use of the
reverse tree anywhere.  It was the discovery of that very gap way back
in 2006 that caused me to try to resurrect Daniel Senie's original
draft and drive it through DNSOP.  I think I was less cynical in those days.

> 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.

Rather than "should" here, I'd prefer to say that it'd be nice if they
work (just so that people don't mistake that should for a 2119 word).
But the distinction you're making is roughly parallel with the
distinction draft-ietf-dnsop-reverse-mapping-considerations-06 made
between existing and matching reverse entries.  I agree this
distinction is worth keeping in mind.  

> 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.

I can assure you that there are people who insist that they _do_ need
to match.  It's also possible to have those multiple matches, as long
as the list is not too long.  I think the view that every forward must
have a matching reverse is somewhat unrealistic; but the last time I
expressed such a strong opinion about the reverse tree I landed in a
long interaction with the proprietor of av8.net, so I'm disinclined to
defend my opinion very hard. 

I do think that the people who think that the reverse tree is entirely
optional are neglecting the interoperability consequences of that
decision.  That interoperation is the only real reason I can see to
maintain the reverse; but it's a pretty important reason!

Best,

A

-- 
Andrew Sullivan
Dyn, Inc.
asullivan at dyn.com
v: +1 603 663 0448




More information about the NANOG mailing list