[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: brain cycles of the WG

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
NeuStar

Dessert - aka Service Pack 1 for lunch.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>