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@dyn.com v: +1 603 663 0448