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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
