Subject: Re: DNS vs. non-DNS Data

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 13 May 2001 12:21:28 -0700

http://www.ehsco.com/misc/draft-hall-dns-data-00.txt is a draft on what I
believe to be appropriate guidelines for DNS data.

   Due to the architectural tradeoffs inherent in the DNS lookup model,
   some usage models are better suited to DNS than others. In
   particular, DNS is highly efficient at lookups of compact, public and
   relatively stable data. Conversely, DNS is unsuitable for value-
   based queries or searches, restricted-access data, highly-dynamic
   data, or large records and arrays.

Note that this does not include my original arguments, which was that DNS
should be used for lookups of distributed data required to establish a
connection, nor does it include the subordinate requirements such as "no
machine-specific data, no local-only data" and so forth.

The reason this restriction is not there is because I have not been able
to find enough data to support or refute the position that the DNS
hierarchy would be overloaded by some N multiple of current lookups. This
doesn't mean that either position is valid, it only means that there is no
evidence to support either position. I can't consider this document
finished without that evidence so I'm not planning on advancing this
document until that data is available. But I wanted to close the argument
loop, so here is what is known.

Regarding the missing data, there are three potential limiters on query
growth: cache size of end-systems, bandwidth of core servers, and query
rate of core servers. Evidence suggests that cache availability might as
well be infinite and that core bandwidth is not likely to become a limiter
anytime soon, which leaves query rate as the only potential bottleneck.
I'm still looking for data in all three areas, and if anybody has anything
to add here I'd appreciate it.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.