On Sat, Mar 31, 2018 at 11:34:29PM +0200, bert hubert wrote: > On Sun, Apr 01, 2018 at 02:39:06AM +0530, Mukund Sivaraman wrote: > > Just a "guide to the RFCs" won't be sufficient. Language has to be > > corrected; large parts of RFC 1034 and 1035 have to be rewritten and > > restructured, incorporating clarifications from newer RFCs. It would be > > a big work, but IMHO, it is necessary. > > First, I agree it is necessary. I don't think anyone would really disagree. > The issue is the stupendous amount of work it would be and if we are going > to do it. > > A secondary question is how hard we are going to make this on ourselves if > we do it. This comprises a number of things: 1) which RFCs would be obsoleted > by the rewrite (2181?)and which ones are we going to leave in place (403x?)
All the clarifications RFCs such as NCACHE 2308, 2181, wildcards 4592, etc. I'd also expect TSIG, AXFR, IXFR and UPDATE to get treatment in "core" DNS in the same grouping as master files. Core DNS can have optional parts such as transfers and updates and even reading/writing master files. Anything expected out of a current nameserver for DNS operations is part of core I'd say. EDNS and TCP would need full treatment. COOKIE is core DNS, and I'd even say mandatory for UDP DNS implementation if we're writing up a revised draft. Kaminsky attack wasn't seriously considered in the year 1987 and amplification attacks weren't a thing. RFC 1034 still calls attention to matching the reply with the query strictly. I'd even put qname minimization there as a SHOULD. BTW, RFC 1034 has a number of nuggets.. e.g., it has language that allows the serve-stale draft. It describes the possibility of draft-muks-dnsop-dns-opportunistic-refresh-00. > > 2) What 'optional' things are we going to move into scope of DNS basics. In > other words, what will 1034/1035-bis say about DNSSEC? Core DNS would have to describe DNSSEC (not just the 403x trio). It may be optional to implement, but the updated resolver and auth algorithms, etc. have to be described. IMHO, about the only things that would not be in core DNS and would be updated in 3rd party RFCs would be RR types and EDNS options that are added along during the run, and/or should be held 10 feet away. > Tbh I highly doubt if we'll have the determination to do 1034-bis given that > even the profile efforts did not succeed so far. > > I will in any case continue to plod away on the 'hello-dns' introduction. I think there's room for the DNS folks to do both paths, i.e., they don't overlap. There's room for Richard Stevens style textbook treatment for DNS anyway, and there's room for a current protocol draft that updates the old specs. I created a repo to collect thoughts too: https://github.com/muks/dnssquash/ Will start by extracting the domain tree description from 1034, tweaking it. If it describes the squashed protocol all in one place, implementors can lookup things in it and that's something worth doing. It is just a lot of editing things into place. Mukund _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
