At 21:23 +0000 12/16/06, Jay Daley wrote:

>I'm also increasingly of the view that DNS is /so good/ that most people
>simply don't realise it. And it is all those complex and weird little
>quirks that enable it to be so good. What worries me about any attempt at
>DNSv2 is that some of the brilliance will be lost by trying to 'fix' DNS
>and DNS is just too important to work in any less good a way.

DNS stands on the shoulders of other naming systems, I am not
surprised that DNS is a good protocol at heart. I don't mean to
disparage the effort by saying that DNS stands on other's shoulders,
it means that it wasn't just a lucky bolt out of the clear blue sky.

I think that what is lost often is what makes the DNS a good
protocol. I work in an area in which DNS is a new beast, a
non-Internet environment. It is interesting to see what "them folks"
think is the best part of DNS. They aspects often cited are the
quick response, the lightweight nature, the robustness. They that I
hear are less enthused about the scaling, etc.

DNS is not perfect though. Some problems are in the architecture for
example CNAME chasing in the authoritative server, the fixed message
size assumptions (in data and header), and message compression. In
the sense of "you've optimized a design when you can't possibly strip
away any more" these are things that probably would have been taken
out if there was better hindsight back then. Outside of CNAME, most
of what I'd take out now were originally put in to handle problems of
15 years ago - namely really constrained bandwidth.

There are other problems with DNS that are accidents of history,
cruft thrown in because of implementation gaffs over time. Mangling
misunderstood types are an example of this, as well as some of the
extra records that BIND threw in years ago that probably ought not to
have been in responses (like the authority records in a
CNAME-impacted response).

A DNSv2 would have to retain the lightweight nature, and make it even
more lightweight. It would also have to remove the limitations of
small fields without adding more to the fields. Finally, it would
have to expand the notion of what's atomic from the RR to the RRset
plus ancillary info. But, please, abandon the hope of negotiating
service parameters - that's heavy weight and adds round trips.

Edward Lewis +1-571-434-5468

Dessert - aka Service Pack 1 for lunch.

to unsubscribe send a message to with
the word 'unsubscribe' in a single line as the message text body.