At 16:39 +0200 12/6/06, Pekka Savola wrote:

> - load balancers and such dropping all queries except 'A'
> - DNS servers giving various sorts of bogus error codes in various
> kinds of conditions (e.g., RFC 4074)
> - Totally broken (in various ways) DNS resolvers out there (e.g., RFC
> 3697)

(Do you mean 3697? Flow-label? I don't see DNS in there.)

> - various pieces of DNS infrastructure not supporting new RR types as
> well as we might like to
> - cache poisoning prevention still having no useful normative
> specification
> - EDNS0 not working very well, e.g., because some products choose
> to drop "too big" DNS packets.

I don't discount that this happens or is a pain. But with the
exception of the penultimate point, what part of that is the result
of the protocol specifications being unclear or missing? E.g.,
handling only A records seems like a choice, not a misbelief that
they are the only records in use.

>Someone better versed with DNS specifications and their implementations could
>continue the list.

That seems to be self-contradictory. Folks well-versed probably
can't see what is unclear.

>All of these have contributed to "dumbing down" the minimum, useful subset
>of DNS. DNSSEC requires more than the minimum subset, which is likely one
>(minor) reason why it likely won't become popular outside fringe communities
>("DNS nerds" you mentioned) any time soon.

What's wrong with something being "dumbed down?" Perhaps it is a
sign that the other clutter we've thrown in over the years is
extraneous complexity. The reason why the DNS was built is to
provide a service to others, not be basis for on-going work.

>Is your point that revising the specs now isn't worth it because we can't wrap
>these new demands in the core DNS spec? Otherwise I didn't quite understand.
>Or did you mean that once the core spec is "opened", worms will sprout out
>and we'll end up with redesigning the DNS to accommodate new functions? My
>intention very specifically was NOT to include any of these search, IDN,
>DNSSEC etc. capabilities in the updated "core DNS" specification.

I think that to do some of the new things that are desired cannot be
accommodated in the code now. Part of that is architectural, part of
that is design, part of that is compatibility with the existing base.
Architectural - that DNS is a lookup, not a search. Design - the
CLASS field is after the label. Compatibility - old code won't cope
so we shoe horn unnaturally.

I also don't think we will get agreement on what is in the core now.
I've kicked around the idea of just doing a profile - a document
listing the other documents that define the protocol, and haven't
been able to get any consensus on what is and is not essential. Not
every one likes AXFR, not everyone does CNAME. If we were to
describe what is absolutely necessary for interoperability only in
DNS, we'd get a mudfight.

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.