"John R. Levine" wr
So my advice would be to back up and write down in one or two
sentences what problem this document is supposed to fix or at least
describe, and then see how much of the rest of it might be salvaged.
I was thinking of storing data in DNS and the document proved valuable to
determine whether its a good idea or not. I mean, not whether it is
technically feasible, but whether it makes sense at all.
So, while the mission statement may be a bit unclear, it's definitely a
I agree that such a document would be useful, but this isn't it.
Applications are poorly suited for the DNS if they need fuzzy matches, or
range queries, or have query patterns that don't cache well. (IPv6 rDNS
has that last problem.) You can argue about how large query and response
sizes should be, although DNSSEC has forced an answer to that one.
Reverse IPv6 caches well. You just can't pre-populate servers with PTR
records for all 2^64 ptr records in a normal IPv6 subnet. You need to
use tools that add records for nodes that actually exist. Those tools
are a decade old now.
Applications that map fixed query names to (more or less) fixed responses
work fine on top of the DNS, even if the query doesn't look much like a
host name and the response looks nothing at all like an A record, e.g.,
A document that described the actual technical architecture of the DNS,
without confusing it with the design of applications built on top of the
DNS would be a good idea. I suppose I could try and write one.
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
Please consider the environment before reading this e-mail. http://jl.ly
Ietf mailing list
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org
Ietf mailing list