In article <5142FE8F(_dot_)1020404(_at_)dcrocker(_dot_)net> 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