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

[Mukund Sivaraman <[e-mail]>]

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