# Re: DNS -- plain vanilla dns please.

John C Klensin (KLENSIN@INFOODS.MIT.EDU)
Sat, 30 Oct 1993 11:27:06 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Erik Huizer: "Re: What URIs are and are not."
- Previous message: Tim Berners-Lee: "URN: criticism, point and protocol."
- In reply to: Fred Swartz: "DNS -- plain vanilla dns please."
- Next in thread: Rob Raisch, The Internet Company: "Re: Single protocol for UR*?"

    Date: Sat, 30 Oct 1993 11:27:06 -0400 (EDT)

    From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>

    Subject: Re:  DNS -- plain vanilla dns please.

    In-Reply-To: <9310300159.AA16229@merit.edu>

    To: fred.swartz@UMICH.EDU

    Message-Id: <751994826.162783.KLENSIN@INFOODS.UNU.EDU>

> From: mitra@path.net (Mitra)
...
>The advantage of NOT adding another DNS record, is that people dont have
>to implement DNS - or obtain libraries that do - in order to get to the
>whois++ server. They can do it all with a single "gethostbyname" call.

# -- Fred (fred.swartz@merit.edu)
# Please do NOT add another DNS record. Mitra's right.

Treat this as a personal observation folks, as anything official/formal/
authoritative will have to come from the DNS WG or Dave Crocker who is
area director in that area, but...

If UR* resolution activities succeed, use of URIs well generate
references at a much higher rate than we've ever seen before with the
DNS. A single densely-referenced HTML or similar document that uses
URNs could easily contain a dozen or more references within a single
paragraph, and a highly optimized hypertext reader, might well be
designed to optimize performance for the user by anticipatory retrieval
of things that *might* be wanted.

The code that accesses the DNS is relatively fragile (although it is
getting better) and it is a periodic source of wonder that the
combination of that code, the present load, and with human errors in
setting up zone files has not caused the whole system to collapse. The
recent "this is what not to do" RFCs on DNS configuration represent
recognition of this problem. DNS-embedded UR* definitions or template
pointers would presumably be subject to the same types of errors in
setting up files, since it would also be humans who are doing the
setting up.

In addition, one of the nice features of the DNS model is that a server
that recognizes the type of information it is being asked to retrieve--
by using type information--can return "additional information" that
usually saves additional round trips. If you overload an existing
type, there is no way to take advantage of this, and you either won't
get additional information records or they won't be relevant. Either
way, you load the system further and reduce user performance.

Creating a potentially-serious performance problem and risking meltdown
of an Internet facility that is critical to almost all applications
today in order to realize a short-term gain in speed of deployment seems
to me like very poor engineering indeed.

If these things are going to go into the DNS, there is a case to be made
for a new Class, not just a new Type--the cacheing and expiration models
might be different for these types of information, and one might even
want to think about a different root server collection.

Just some thoughts...
john

- Next message: Erik Huizer: "Re: What URIs are and are not."
- Previous message: Tim Berners-Lee: "URN: criticism, point and protocol."
- In reply to: Fred Swartz: "DNS -- plain vanilla dns please."
- Next in thread: Rob Raisch, The Internet Company: "Re: Single protocol for UR*?"