On Fri, Mar 06, 2009 at 04:42:29PM -0800, Doug Otis wrote:
When there is to be reverse namespace, it should be ensured to work. In
reality, this is not always the case.
That is either an impossible goal, or else a meaningless requirement.
In some sense, the reverse tree always works: you send a query in, and
you get the answer that the global distributed database can give you
(one of which is, "dunno -- I didn't get an answer in time, so I gave
up").
What you might asking for with "ensured to work" is what the
reverse-mapping-considerations draft calls "existing reverse data".
The idea is roughly that, for any address-type answer from a forward
zone, if you query that address in the reverse zone you get some
positive answer (e.g. you get a PTR record).
What I suspect you're asking for with "ensured to work" is what the
reverse-mapping-considerations draft calls "matching reverse data".
The idea here is roughly that the PTR record you eventually get
corresponds to the name you originally queried.
Regardless of which of the latter two you want, however, the fact is
that the reverse tree is only ever going to be as operative as the
operators of those reverse trees make it. Since we have plenty of
examples of bizarrely broken behaviour in a forward zone, there's no
reason to imagine that the reverse is somehow special and more likely
to work. Therefore, I say the goal is impossible.
Reverse namespace is often used to determine, by the nature of the PTR
labels, whether an IP address might be dynamically assigned before
deciding to accept email from a specific IP address.
That very practice is one of the more contentious pieces around the
draft. If you want to discuss this further, I encourage you to take
the discussion to DNSOP, where the draft was last considered, since
that's the WG that will have to be persuaded to send the document
along if it is to go anywhere.
Best,
A
--
Andrew Sullivan
ajs(_at_)shinkuro(_dot_)com
Shinkuro, Inc.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf