In article <5142FE8F.1020404@xxxxxxxxxxxx> you write: > >Review of: Architectural Considerations on Application Features in > the DNS > >I-D: draft-iab-dns-applications-07 > >Reviewed by: D. Crocker I had similar comments to Dave's on earlier versions of this draft, and although I think the recent draft is more of an improvement than he seems to, it still has deep problems. For me, the worst problem is that it's utterly unclear what it's trying to say, and whether it is describing functional problems (e.g., DNS responses that are too large for UDP) or aesthetic ones (the complex way that NAPTR is used, even though the DNS lookups are dead simple.) It would be a help if the documents' authors could explain in a few lines what they're trying to say. I'm aware of some fairly clear technical advice one might give about DNS suitability, e.g.: * keys must be domain names * no fuzzy matching beyond case folding and what DNS wildcards do * name space must map reasonably into DNS tree (we can argue about whether _prefix is reasonable) * values must work as an unordered set of typed records * values must not be too big, for some version of too big * names that look related may not be, tree walks are bad * lookup patterns that cache well are good etc. I think those are all in the current draft, but they're mixed in with a lot of other stuff the point of which is hard for me to understand. Here's a concrete example of the sort of question that I would hope this draft would answer: last year I was thinking about how to do DNS blacklists and whitelists for IPv6 addresses sending e-mail. The obvious approach would be to adapt the design of rDNS and assign a domain name to every possible IP address, then look up that name to see if it's blacklisted or whitelisted, like we do with IPv4 addresses. The problem is that it would be trivial for a hostile sender to hop to a new IP address for each new message, leading to a different DNS query, which would have dreadful cache behavior and overload servers. So I came up with a completely different approach adapted from database B-trees, a bushy tree of blocks of data representing lists of address ranges. The key for each block is the lowest IP address described by that block as a hex number followed by the name of the BL, e.g, 1234567812345678.bl.example, the data in each block is a bunch of variable length binary fields stashed in a TXT record. (Despite its name, a TXT record can contain arbitrary binary data.) The data in each block tells whether it needs to look at another block, and if so the exact name of that block. A little testing confirms that the number of lookups is quite reasonable, and the structure of the database means that most lookups will be satisfied from the local DNS cache. The details are in expired draft draft-levine-iprangepub-02. Is this an appropriate use of the DNS? It looks up fixed keys to get moderate sized results, and the lookups cache well. It shares the NAPTR aspect that the records are complex and don't look anything like A or AAAA records, and the processing to use them is quite complex, albeit well defined. I would want to be able to look at this draft to figure out the answer. As it stands, I can't. R's, John