Re: [DNSOP] Current DNS standards, drafts & charter

[Michael Casadevall <[e-mail]>]

So, a couple of thoughts as a newcomer to the list, and someone who's
wading through the virtual forest that is the DNS RFC specifications.

Breaking into the DNS world is to put it ... difficult. I thought myself
relatively knowledgeable on the subject up until about two weeks ago
when I subscribed and began making his way through the backlog of RFCs.
RFC 1034/1035 describes the gist of the DNS protocol but a lot of
details are hard to follow, and as time has shown, a lot of DNS is devil
in the details as resolvers have a bad tendency to eat anything that
isn't a basic A record.

Even beyond that, there are likely features of DNS that would probably
break in two if we tried them on the public internet such if a new DNS
class beside IN or HS was ever introduced, and the usual pain that
happens when a new RRtype is added.

I think the DNS Camel page is very much a good start, and it's at least
given me a targeted reading list but those specifications handle both
the server-side aspects and the client side aspects. A targeted list of
"This is what you need to read and what sections if you're implementing
a resolver" and a converse list of "Here's the server-side specs".

A link to a DNS test suite (if such a thing exists) where a resolver or
server implementation can be tested for good behavior would go a long
way which goes through each RFC and tests behavior against a set of
reference data would at least help show that an implementation is
complaint with the RFCs as written. This would also go nicely with "all
specs must have an implementation" point that has been brought up.

That changes the conversation from "If you want to build a resolver,
read the RFC equivalent of War and Peace" to "Read this [insert shorter
book], and make sure this test harness passes with your resolver".

As far as obsoleting parts of the specification with more documents,
often times, at least with the current discussion on MB, MAILA,etc,
there are compatibility concerns that need to be noted. While it might
be valid say "Just don't implement X in your code", I'd be concerned if
there was just a random IETF webpage with that info and not a bonified
RFC behind it since RFCs are the canonical source for these kind of things.

At the end of the day, I don't know how much it's going to help the
'archive panic' of getting up to speed with DNS. The simplest thing I
can think to implement in the DNS world is an absolute bare bones stub
resolver. At a minimum to meet modern standards, you'd have to work
through RFC1034/35 (core implementation), 2535 (AD/CD bit), 3226 (IPv6
MTUs, ignoring everything else on A6) 3596 (AAAA IPv6), 4592 (wildcard
handling), every RFC that defines a RRtype due to compression of well
known types, and probably a bunch more that I'm unaware of or couldn't
find with a quick search. Much relevant information is buried side by
side with obsolete info.

At best the reading list can be shortened, but it's not going to help
with the fact that RFC 1034/5 is awkward to read.

Michael