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 a...@shinkuro.com Shinkuro, Inc. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf