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

From: bert hubert <[email-masked]>
Date: Mon, 26 Mar 2018 17:46:45 +0200

Hi everyone,

I've been looking at the amount of DNS out there, and I think we can do
several things with them. I've also concluded that the mediocrity of DNS
implementations outside of the well-known ones can not be fully blamed on
"stupid programmers". The fact that we've offered the world 1000-2000 pages
to read, with no guideline where to start, is also very likely to have
contributed.

In fact, to this day, if someone wanted to 'get' DNS to implement a server,
I can do no better than point them at 1034/1035 which are pretty archaic by
now and not easy to read. A bit like reading the original Shakespeare. It is
English, but a lot of the words are different. (also, still pretty
insightful stuff).

I am optimistic that if we had a better 'hello, and welcome to DNS' document
we could point to, implementations would get better.  Or if they didn't, we
could at least point at that document and blame them for not reading it. 
This may prevent implementations that get confused if they get anything
other than an A query.

So my first suggested action is: could we write a document that has a core
introduction of DNS and then provides a recommended (not) reading list.

Secondly, what we've been doing already, is grouping the various standards
in categories.  Read this if you are doing X.  This could go in the first
document.

Thirdly, this may lead to a category of RFCs that you might be better off
not reading or implementing. I don't know if writing a draft that
specifically obsoletes record types or features that are never used is
helpful. In fact, adding MORE documents to the pile (even if meant to make
life easier) may be counterproductive. But simply noting that something
should not be implemented anymore would do rhe trick.

Fourthly, on the currently active drafts aiming to become Internet Standards
(with page numbers):

DNS Multiple QTYPEs 6
Secret Key Transaction Authentication for DNS (TSIG)	21
Address-specific DNS Name Redirection (ANAME)	11
C-DNS: A DNS Packet Capture Format	58
Extended DNS Errors	8
A Root Key Trust Anchor Sentinel for DNSSEC	14
Let 'localhost' be localhost.	9
Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY	10
Security Considerations for RFC5011 Publishers	18
Serving Stale Data to Improve DNS Resiliency	9
DNS Stateful Operations	49
BULK DNS Resource Records	14
A DNS Query including A Main Question with Accompanying Questions	10
Returning extra answers in DNS responses.	8

These represent 245 pages of new reading material, or an increase of over
10% on the already impressive list of DNS standards.

I did a cursory read of the DNSOP charter, and I think at least some of
these drafts do no not fall under even a very broad interpretation of our
remit.

And the BCP/Informational/Experimental ones:
The ALT Special Use Top Level Domain	10	INFORMATIONAL
DNS Scoped Data Through '_Underscore' Naming of Attribute Leaves	8	BEST CURRENT PRACTICE
DNS Transport over TCP - Operational Requirements	14	BEST CURRENT PRACTICE
An Proxy Use Case of DNS over HTTPS	5	EXPERIMENTAL
Reverse DNS in IPv6 for Internet Service Providers	13	INFORMATIONAL
DNS Terminology	42	BEST CURRENT PRACTICE
DNS Catalog Zones	14	EXPERIMENTAL

Similarly, we might give these a good scan to see what we think of these.

Finally, with Job Snijders, I am very much in favour of mandating
interoperable implementations as a requirement for standards action.  There
is a whole bunch of reasons for this.  For starters, how can we know if an
idea is good without having tried it?

Secondly, getting implementations to support this is an instant damper on
ideas which would not get traction with implementations later on. 

And thirdly, I think it is extremely educational to experience how a feature
that is 'easy' on the authoritative side (say, DNS Multiple QTYPEs)
absolutely sucks and leads to probing on the resolver side - requiring whole
factors more code than the spec is actually about.

Thoughts?

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Mar 2018 09:13:31 -0700

bert hubert wrote:
> ...

i agree with your observations, and i like your first and second 
suggested actions.

> should not be implemented anymore would do rhe trick.

let's consider marking some things as mandatory to implement, and then 
anything not so marked will be, by exclusion there, optional to 
implement. this is not the same as deprecation, and comports with your 
later observation as follows...

> interoperable implementations as a requirement for standards action.
> There is a whole bunch of reasons for this.  For starters, how can we
> know if an idea is good without having tried it?

...but, i think that multiple interoperable implementations is already a 
minimum benchmark, and i think it's IETF-wide, not optional, and has 
always been in effect here.

what i'd like is something more. KEY, SIG and NXT had multiple 
interoperable implementations, but were not actually functional in any 
end-to-end way, and were thus replaced by RRSIG, DNSKEY, DS, and NSEC. 
later we moved the target and added NSEC3 and then NSEC3PARAM.

so while multiple interoperable implementations are a minimum benchmark, 
i'd like to see some kind of scale model as well. making something work 
on a whiteboard, or in a test lab, or on one's laptop, does not mean it 
will work on today's or tomorrow's internet.

this just amplifies my interpretation of your term, "having tried it."

> ideas which would not get traction with implementations later on.

sadly, this is not so -- thus the above "scale model" requirement.

> factors more code than the spec is actually about.

this again goes to scale modeling and the definition of "having tried it."

> Thoughts?

anybody can complain about the weather, but very few of us try to change 
it. thanks for your contribution to complexity considerations.

-- 
P Vixie

---

From: Martin Hoffmann <[email-masked]>
Date: Mon, 26 Mar 2018 18:24:43 +0200

bert hubert wrote:
> 
> I've been looking at the amount of DNS out there, and I think we can
> do several things with them. I've also concluded that the mediocrity
> of DNS implementations outside of the well-known ones can not be
> fully blamed on "stupid programmers". The fact that we've offered the
> world 1000-2000 pages to read, with no guideline where to start, is
> also very likely to have contributed.

The thing that trips me up implementing DNS without intimate
knowledge of the assorted RFCs isn't the amount of them -- 2000
pages isn't all that bad if you come from SIP. Rather, it is that
important details are hidden all over the document base, often
in unexpected places. As an example, the SOA minumum field is
(re)defined in RFC 2308 which nominally talks about negative
caching, something I'd probably ignore if I implement a
simple authoritative server.

So, I'll step on that mine: What really would help new
implementers is a 1034bis.

Kind regards,
Martin

---

From: Job Snijders <[email-masked]>
Date: Mon, 26 Mar 2018 16:30:02 +0000

On Mon, Mar 26, 2018 at 09:13:31AM -0700, Paul Vixie wrote:
> ....but, i think that multiple interoperable implementations is
> already a minimum benchmark, and i think it's IETF-wide, not optional,
> and has always been in effect here.

Nope, that is not the case. This is why IDR has explicit Working
Group-specific rules regarding this topic. Please review
https://mailarchive.ietf.org/arch/msg/dnsop/9f3W3YcmFLvXq4ZFOsteyCgxhHY

> so while multiple interoperable implementations are a minimum
> benchmark, i'd like to see some kind of scale model as well. making
> something work on a whiteboard, or in a test lab, or on one's laptop,
> does not mean it will work on today's or tomorrow's internet.
> 

Agreed.

Kind regards,

Job

---

From: Paul Vixie <[email-masked]>
Date: Mon, 26 Mar 2018 09:31:49 -0700

Martin Hoffmann wrote:
> ...
>
> So, I'll step on that mine: What really would help new implementers
> is a 1034bis.

i sympathize with this view, but here's my worry:

> That having been said, a stronger document set written today would
> not be able to put all of the DNS genies back into their bottles. Too
> many implementations have guessed differently when presented with a
> loose specification, and interoperability today is a moving, organic
> target. When I periodically itch to rewrite the specification from
> scratch, I know there are too many things that must be said that also
> cannot be said. It’s as though, in a discussion of the meaning of
> some bit pattern, a modern description of the protocol—written with
> full perspective on all that has been done in the DNS field—would
> have to say, “It could mean x but some implementations will think it
> means y so you must be cautious.”

(https://queue.acm.org/detail.cfm?id=1242499)

what this means is, it's a difficult task.

-- 
P Vixie

---

From: Michael Casadevall <[email-masked]>
Date: Mon, 26 Mar 2018 12:48:31 -0400

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

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 26 Mar 2018 19:26:20 -0400

Hi all,

First, thanks for running with this.

Top-posting a couple of process observations:

First, the chairs are always open to discussion of what documents belong in the WG, interpretation/revision of our charter, etc. There’s a certain amount of process to be observed, especially if we want to revise our charter, but nothing unmanageable; it’s the chairs’ job to make process work for the WG rather than the other way around.

The current DNSOP charter was deliberately written to be flexible in what we could work on. Normally an IETF WG is chartered to perform a fairly tightly constrained piece of work and then either re-charter to an equally specific next work item, or shut down. But part of the purpose of keeping DNSOP around in a slightly more open-ended fashion was that the community seemed to believe that major protocol work on DNS was done, but there would still be pressure to provide for small tweaks on the wire and review Informational documents on operational practice such as DNSSEC maintenance.

Since then, a couple of pieces of work with significant protocol implications have gotten some initial review in DNSOP, and then moved to new WGs such as DPRIVE. Most of the documents DNSOP publishes are standards track only for procedural reasons— implementing them is strictly optional for interoperability on the public internet— or are informational.

If the WG feels that the previous view of how DNSOP should work has been overtaken by events, we can certainly work with our Area Director (hi Warren!) on a revised charter.

Given the deliberately loose boundaries on the current charter, we can adjust what we’re doing instead of (or during) the formal process of revising it. The charter we have doesn’t obligate us to adopt any particular work item, or to pursue one that’s been adopted but that the WG finds it doesn’t want to pursue after all. 

In my own strictly subjective impression, some of what we’re publishing is first written as an internet-draft….but some is implemented first in the field and then brought back to the IETF to be documented in an informational RFC so other implementers can write compatible behavior into their software, or so operators who want to use a particular feature can figure out how (*lots* of DNSSEC docs), or operators who don’t want to use a particular feature can (relatively) easily find ways around it. 

The pressure to standardize extensions to the DNS actually seems lower in the last few years, because both the RRtype registry and the EDNS opt registry policies are expert review rather than standards action. However, the tendency to desire DNS-over-new-transport is recent. So is DPRIVE. So are the assorted optimizations used by CDN operators such as serve-stale and client-subnet.

It’s also worth noting that many WG participants (operators and implementers alike) have argued over the years that having the IETF refuse to publish an RFC does nothing to discourage people from inventing and fielding new features, it just makes it harder to find out what they’re doing— whether you want to interoperate with them or simply avoid them. So for novel uses of RRtypes or EDNS options, we’ve tended to encourage people who already had acquired code points in the registry to document what they’re doing with them (see RFC 7871 on client-subnet, which had a code point and was in widespread use and *then* was brought to DNSOP).

Serious question: should we be encouraging people to document these optional extensions in RFCs?

A couple more points inline:

> On Mar 26, 2018, at 11:46 AM, bert hubert <[email-masked]> wrote:
> 

As discussed at the mic last Tuesday, I believe this is where DNSEXT got hung up, too: it’s likely to be hard work (given the effort that’s gone into just the terminology documents) and may not be considered the best use of people’s time by their assorted funding sources.

Earnest question, for discussion: should this document be an RFC, produced in the IETF? (I can see arguments both ways).

While we ponder this, there’s nothing to prevent anyone from posting a rudimentary internet-draft for consideration. 

> should not be implemented anymore would do rhe trick.

There are process rules around obsoleting or updating an RFC with a new one. They’re not onerous. But for the older RFCs, this could be more complicated than it sounds; a patch is going to be much harder to write than new text in several cases. (I saw a plan once to update RFC 2181 that involved six new documents; each would update or obsolete one section.)

> these drafts do no not fall under even a very broad interpretation of our

Not all of these are WG documents (“candidate” just means someone has asked; bulk-rr for instance), and see above on the charter. 

The chairs don’t adopt documents we believe are off-charter, and would hope for pushback from the WG or our AD if we did. 

But in the context of the “Camel Problem,” arguing about the charter seems less useful than asking ourselves if we’re having second thoughts about the usefulness of documents the WG has adopted, or been asked to adopt. 

(This is long enough already, so further thoughts as the thread evolves. I do think it’s important to pursue the discussion.)

Best,
Suzanne

---

From: Artyom Gavrichenkov <[email-masked]>
Date: Tue, 27 Mar 2018 02:38:07 +0300

On Tue, Mar 27, 2018 at 2:26 AM, Suzanne Woolf <[email-masked]> wrote:
> The current DNSOP charter was deliberately written
> to be flexible in what we could work on. Normally an
> IETF WG is chartered to perform a fairly tightly
> constrained piece of work and then either re-charter
> to an equally specific next work item, or shut down.
> But part of the purpose of keeping DNSOP around
> in a slightly more open-ended fashion was that the
> community seemed to believe that major protocol
> work on DNS was done, but there would still be
> pressure to provide for small tweaks on the wire
> and review Informational documents on
> operational practice such as DNSSEC maintenance.

As Martin Hoffman has pointed out before, this looks very close to
what SIP has faced before. They finally came up with a dispatch WG
[RFC7957], and recently, Security Area also went in that direction. Is
it something dnsop WG might also consider as a viable solution to the
protocol complexity issue?

| Artyom Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: [email-masked]
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 27 Mar 2018 09:49:07 +0200

Hi Suzanne,

> If the WG feels that the previous view of how DNSOP should work has been overtaken by events, we can certainly work with our Area Director (hi Warren!) on a revised charter.

I strongly believe that any work on cleaning up DNS protocol and/or rewriting RFC1034/RFC1035 and associated document would need a new WG with tightly defined charter.

Hence, I will not request or I won’t support adopting my deprecating-obsolete-rr-types as a WG document - it might become one of the first documents for new WG, or it might end up as individual submission. While this work might be considered as “protocol maintenance”, I think it is bigger then simple protocol maintenance.

Again, from experience from dnsext, I would strongly suggest that any work in this area is split into CHANGE documents and REWRITE documents, with strict scope. Documents rewriting existing RFCs while adding more stuff at the same time tend to not reach the finish line.

Ondrej
--
Ondřej Surý
[email-masked]

> On 27 Mar 2018, at 01:26, Suzanne Woolf <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Wouters <[email-masked]>
Date: Tue, 27 Mar 2018 07:51:23 -0400 (EDT)

> Hence, I will not request or I won’t support adopting my deprecating-obsolete-rr-types as a WG document - it might become one of the first documents for new WG, or it might end up as individual sub…

I agree. If this is a task worth doing, do it in a new WG.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 27 Mar 2018 08:10:41 -0400 (EDT)

On Mon, 26 Mar 2018, Paul Vixie wrote:

> what i'd like is something more. KEY, SIG and NXT had multiple interoperable 
> implementations, but were not actually functional in any end-to-end way, and 
> were thus replaced by RRSIG, DNSKEY, DS, and NSEC. later we moved the target 
> and added NSEC3 and then NSEC3PARAM.

The way I remember this is that while while the KEY/SIG/NXT didn't
provide the chain of trust, it was otherwise functional and DS could
have been added here.

The desire to only allow DNS to use the KEY record (and exclude IPsec
keys) was the main drive to rename/renumber these to DNSKEY/RRSIG/NSEC.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Mar 2018 08:55:35 -0700

> provide the chain of trust, it was otherwise functional and DS could

the question i'm begging here is why was something RFC'd that could not 
possibly have worked other than on a whiteboard or test lab, not exactly 
which parts could have been kept. we ought to have required a scale 
model of the resulting system -- which would have required a much larger 
test lab -- before we let that draft or any draft move forward.

this would have caught the IP fragmentation design flaw in EDNS, also.

> keys) was the main drive to rename/renumber these to DNSKEY/RRSIG/NSEC.

according to the records, TCR was nec'y in order to facilitate DS. see:

https://tools.ietf.org/id/draft-weiler-dnsext-dnssec-2535-compat-00.txt

-- 
P Vixie

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Mar 2018 12:02:16 -0400

Hi,

> introduction of DNS and then provides a recommended (not) reading list.

Maybe we could, but we failed at that once before.

After the DNSSEC work wound down, around IETF 68, DNSEXT went
"dormant".  But it was apparent that the DNS protocol was complicated
and difficult to understand, so the WG was rechartered partly to try
to get some clarity to the standards.  The document the WG hung its
efforts on was
https://tools.ietf.org/html/draft-ietf-dnsext-dns-protocol-profile-01.

The problem, of course, was that nobody had the time required to
complete this.  I have no idea how the SMTP crowd at the IETF manged
to get the cycles to update 821/822 several times, but we were unable
to get this energy.  The last update to that draft came in January
2008, and by IETF 72 (in July of '08) Olafur and I concluded that, if
we couldn't get any activity, then we'd try to focus the WG on places
where it could make progress.  We took that decision in the fall of
2008.

Now, I don't think that the work was bad or wrong, and I think that
draft remains a useful place to start if people want to pick up that
work again.  But I'm not super convinced that this or any other WG
really will have the desire to undertake it.  Maintenance is no fun,
and inventing new stuff is more entertaining.

But, by all means, if people want to revisit that effort, I think it
would be a fine thing.  I think, however, that someone should contact
a friendly neighbourhood AD to try to determine where the work should
be chartered.  I do _not_ think it is operations and management work.

One thing that would be interesting to explore in taking that effort
up is whether DNS should really be considered INT or ART.  DNS lives
squarely in the application layer and isn't really like the other
things that fit in INT.  OTOH, it's more a service to other parts of
the network than it is an application the way ordinary application
layer things are.  The misfit of the model to the world strikes again!

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 27 Mar 2018 12:19:56 -0400

On 27 March 2018 at 03:49, Ondřej Surý <[email-masked]> wrote:

>
> Again, from experience from dnsext, I would strongly suggest that any work
> in this area is split into CHANGE documents and REWRITE documents, with
> strict scope. Documents rewriting existing RFCs while adding more stuff at
> the same time tend to not reach the finish line.
>
> Does this include combining documents?  For example, it would probably
make sense to combine some of the clarifications documents into any rewrite
of 1034/1035.

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 27 Mar 2018 18:27:48 +0200

Definitely. I didn’t mean to rewrite 1:1, but take existing content and do m:n including splitting and combining existing RFCs into new document(s).

Ondřej 
--
Ondřej Surý — ISC

> On 27 Mar 2018, at 18:19, Matthew Pounsett <[email-masked]> wrote:
> 
> 
> 
> Does this include combining documents?  For example, it would probably make sense to combine some of the clarifications documents into any rewrite of 1034/1035. 
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 27 Mar 2018 09:41:40 -0700

> Maybe we could, but we failed at that once before.

Oh, there you go again with that operational history lesson. :-)

> complete this.

We hope that someone does, but rarely can we find someone whose boss 
will give them the (literally) hundreds of hours that would take to do 
this right.

> I have no idea how the SMTP crowd at the IETF managed
> to get this energy.

OK, my turn. I ran the Internet Mail Consortium during the timeframe of 
that work, and helped shepherd some of the discussions and the interop 
testing. It was grueling even though that was a group of people where 
pretty much everyone liked each other and listened politely.

> The last update to that draft came in January

 From the SMTP work above, I would also say "...and unless you have an 
author who can commit a lot of time over the course of two years".

> layer things are.  The misfit of the model to the world strikes again!

This was another area where the SMTP work had an advantage: we got good 
help from others in the Apps Area at the time.

--Paul Hoffman

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Mar 2018 14:33:05 -0700

i see no purpose in change documents, which would add to the set of 
things a new implementer would have to know to read, and then to read.

rather, we should focus on a DNSOP document set that specifies a minimum 
subset of DNS which is considered by the operational community to be 
mandatory to implement. any implementer can remove anything else and 
still be checklist-compatible when customers are baking things off.

if someone wants to implement iquery or WKS let that be crazy rather 
than broken -- on-the-wire patterns still described, code points still 
reserved, but unlikely to find anybody to actually interoperate with.

vixie

re:

Matthew Pounsett wrote:
>
>
> On 27 March 2018 at 03:49, Ondřej Surý <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Again, from experience from dnsext, I would strongly suggest that
>     any work in this area is split into CHANGE documents and REWRITE
>     documents, with strict scope. Documents rewriting existing RFCs
>     while adding more stuff at the same time tend to not reach the
>     finish line.
>
> make sense to combine some of the clarifications documents into any
> rewrite of 1034/1035.
>

-- 
P Vixie

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 27 Mar 2018 19:22:54 -0400

On 27 March 2018 at 17:33, Paul Vixie <[email-masked]> wrote:

> i see no purpose in change documents, which would add to the set of things
> a new implementer would have to know to read, and then to read.

I think we're discussing the same idea from different perspectives.

I think writing a new document that references other documents to say
"here's the sections in each of these you need to implement" without
actually making  any of them clearer is unhelpful, and just adds to the
pile of documents that an implementer needs to read.  While I recognize
there's already been one failed attempt at this, I'd still much prefer we
replace as much of that stack as possible with a smaller set of clearer
documents.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Mar 2018 17:17:02 -0700

Matthew Pounsett wrote:
>
>
> On 27 March 2018 at 17:33, Paul Vixie <[email-masked]
> <mailto:[email-masked]>> wrote:
>

i think so, yes.

> pile of documents that an implementer needs to read.

that's not what i heard bert propose, and it's not what i'm thinking. 
where an older document is not clear, its intent should be restated in 
modern language with modern understanding. where an older document is 
clear, we can refer back to it. if the balance ever tips, then some 
future generation of protocol developers can obsolete older documents in 
their entirety, because the useful parts have all been restated or cut 
and pasted.

> While I recognize there's already been one failed attempt at this,
> I'd still much prefer we replace as much of that stack as possible
> with a smaller set of clearer documents.

this is what i want. we should aim for a living RFC that's reissued from 
time to time as the mandatory-to-implement subset inevitably grows. i 
have no appetite for obsoleting 1035, but i do want a new implementer to 
be referring to it as directed by a more modern document, rather than 
reading it and wondering what parts are still in effect.

-- 
P Vixie

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 28 Mar 2018 04:38:24 -0400

I have looked at the same problem Bert has, but he did present it much 
better than I could.  When I started thinking about this, I approached 
it from the point of view of "If I have to give a co-worker a document 
on how to build a DNS Server (Authoritative or Resolver), what would I 
need to give them".   I also have spent a lot of time watching the 
793bis work in TCPM, which has been moving along slowly and 
methodically.  I felt what we would come up with would be
     1. a DNSOP document which would be an implementation list for 
building an Authoritative or Resolver
     2. a roadmap to work on 1034bis and 1035bis, which would be a new WG.

I also realized that the second item would be brutal, painstaking, not 
"sexy" for most IETF standard types.

I've had lots of experience dealing with the concept of "technical debt" 
and a lot of this is very similar.  But we also need someone who has the 
skill set of a project manager, who knows how to lay out workflows.  
That's not something a bunch of programmers always have.

Summary - Paul is on the right track here.    A good example is looking 
at what Route 53 implements (for better or for worse) and realize they 
implement some real minimal subset.   I think it's too small, but it's 
an interesting argument.

tim

On 3/27/18 17:33, Paul Vixie wrote:
> rather, we should focus on a DNSOP document set that specifies a 
> minimum subset of DNS which is considered by the operational community 
> to be mandatory to implement. any implementer can remove anything else 
> and still be checklist-compatible when customers are baking things off.
>

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 28 Mar 2018 09:41:34 -0400

Note this discussion has started to split into (at least) two: cleaning up the DNS standard (protocol, documents, or both), possibly in a new WG; and whether/how the existing DNSOP WG needs to adjust its efforts. 

> On Mar 27, 2018, at 3:49 AM, Ondřej Surý <[email-masked]> wrote:
> 
> Hi Suzanne,
> 

This all makes sense to me. 

I have no opinion (yet) on what the desired output should be (some new RFCs? A reference implementation/RFC set? Something else?), but agree it doesn’t fit DNSOP.

Personally I think it’s within charter for DNSOP to facilitate this discussion, permit it to stay on the WG mailing list, etc. while people work out how they want to approach it, in substance and process. For instance, DNSOP helped get DPRIVE going by having a session at an IETF meeting on the DPRIVE drafts and adopting one of them (QNAME minimization). The important thing should be whether there’s an identifiable work item and whether the will exists to get it done, not how to charter a WG or otherwise work the process machinery. There are quite a few DNSOP (and IETF) regulars who are current or past WG chairs, ADs, and document editors, with experience of making the IETF machinery turn, who would be happy to advise proponents. This includes the current DNSOP chairs and AD.

I do have to say I support the warnings about getting bits committed to documents (and possibly code). As another anecdote to add to the stack, I remember (as I assume Paul Vixie, Matt Larson, Rob Austein, Ed Lewis, and Roy Arends do) the effort it took to get the DNSSEC RFCs done: a series of interop workshops, a couple of open source companies sponsoring development in well-known code bases, and money to support production of both code and documents. Resources committed as an afterthought were not getting it done. 

This is a different project, and I think it’s doable, but it’s not a weekend undertaking. 

Suzanne

---

From: tjw ietf <[email-masked]>
Date: Wed, 28 Mar 2018 09:58:31 -0400

I should qualify my comments on Route 53 - I don't think they are something
we should emulate, more of an example of how 3rd party vendors get away
with an overly-minimal set of resource records.   The words I have to
describe them are generally not polite.

Tim

On Wed, Mar 28, 2018 at 4:38 AM, Tim Wicinski <[email-masked]> wrote:

> better than I could.  When I started thinking about this, I approached it
> from the point of view of "If I have to give a co-worker a document on how
> to build a DNS Server (Authoritative or Resolver), what would I need to
> give them".   I also have spent a lot of time watching the 793bis work in
> TCPM, which has been moving along slowly and methodically.  I felt what we
> would come up with would be
>     1. a DNSOP document which would be an implementation list for building
> an Authoritative or Resolver
> skill set of a project manager, who knows how to lay out workflows.  That's
> not something a bunch of programmers always have.
>
> Summary - Paul is on the right track here.    A good example is looking at
> what Route 53 implements (for better or for worse) and realize they
> implement some real minimal subset.   I think it's too small, but it's an
> interesting argument.
>
> tim
>
>
>
>
>> mandatory to implement. any implementer can remove anything else and still
>> be checklist-compatible when customers are baking things off.
>>
>> if someone wants to implement iquery or WKS let that be crazy rather than
>> broken -- on-the-wire patterns still described, code points still reserved,
>> but unlikely to find anybody to actually interoperate with.
>>
>> vixie
>>
>> re:
>>
>> Matthew Pounsett wrote:
>>
>>>
>>>

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 28 Mar 2018 11:23:57 -0400

On 27 March 2018 at 20:17, Paul Vixie <[email-masked]> wrote:

> clear, we can refer back to it. if the balance ever tips, then some future
> generation of protocol developers can obsolete older documents in their
> entirety, because the useful parts have all been restated or cut and pasted.

So yes.. we are on roughly the same page.  I'm not a huge fan of meta-RFC
reading lists, even for documents that are fairly clear, but it's hugely
preferable to the current situation.

One of the things I have never liked about the RFC series is the lack of
clarity in an Update document.  I always thought an RFC that Updates
another should be required to state unequivocally which sections of the
older document are obsoleted or, which "new" sections of the older document
the new document creates.  Changing a section in part should never have
been allowed.

Creating those references where they don't already exist and putting them
in a new RFC potentially increases clarity, but also increases the
complexity of the reading material; I'd much prefer we reduce both.

> time to time as the mandatory-to-implement subset inevitably grows. i have
> no appetite for obsoleting 1035, but i do want a new implementer to be
> referring to it as directed by a more modern document, rather than reading
> it and wondering what parts are still in effect.
>

I think 1035 is the prime candidate for being obsoleted by new documents.
It's been updated and clarified so many times, and there are so many
undocumented workarounds of its underspecification, that the reading
required to understand what parts of it are in force is incredibly
discouraging.  There are lots of more modern documents that can stand on
their own as long as they are updating a clear core specification, but
we're missing that clear core specification in the first place.

Now here's a document series process question... if RFCs B & C update A,
and D is written to combine and obsolete A & B, what do you do with the
meta-data on C?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Mar 2018 09:57:03 -0700

tjw ietf wrote:
> I should qualify my comments on Route 53 - I don't think they are
> something we should emulate, more of an example of how 3rd party vendors
> get away with an overly-minimal set of resource records.   The words I
> have to describe them are generally not polite.

i remember being unhappy to see that opendns didn't return an authority 
or additional section. but it's clear that this overminimalism did not 
hurt them in the market. so i think we have to be extremely cautious in 
how we word "mandatory to implement" and what we select to be such.

-- 
P Vixie

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Mar 2018 13:02:39 -0400

A while back, I realized that I needed a full DNS client implementation to
do proper DNS discovery. So I reduced the existing specs to a file that
does capture the syntax:

https://github.com/hallambaker/Mathematical-Mesh/blob/master/Libraries/Goedel.Discovery/Domainer.domainer

I use that file to generate implementations of the parsers for client and
server for both the wire and config file format in c#. The same generator
could be used to generate implementations for C, go or whatever. The file
could be annotated with descriptive matter and used to generate a draft
with consolidated syntax.

Going further than a consolidated, consistent reference becomes tricky
because the group would have to decide on what the DNS architecture has
become. It certainly is not what it was intended to be. Whether it is now
one thing is debatable and there would be arguments.

Harder still would be to get progress on what the architecture should be in
the future. Nothing invites ideology more than the topic of naming and one
of the biggest problems is that there are too many folk who consider
themselves to be the supreme, infallible and sole expert on the topic to
the point. I was once in a WG in another forum where 30 people got into a
room and 29 of them managed to convince themselves that the world would
embrace a protocol in which an account identifier was
http://just.how.stupid.is.this.com/alice.

My view is that naming in a protocol architecture is whatever meets the
needs of the protocol and in particular of the users. Consistency is also
important but that does not justify insisting on something that
consistently fails to meet the needs of users.

If we were to re-engineer the DNS protocol, I would apply the following
principles:

1) Separate the client-resolver and resolver-authoritative protocols.

These are separate problems and should be supported independently because
they have entirely different deployment bases. If we ever want to change
the DNS protocol, we will have to consider the two deployments as entirely
separate.

So for example, let us imagine someone invents a new resolver-authoritative
protocol which is more efficient, aware of DNSSEC, SRV and geo-location
issues, etc. Such a protocol would be focused on the problem of optimizing
the process of cache update. It might even be push-based rather than pull.
Such a protocol would adopt the DNS data model and record structure but
could change everything else. It could probably deliver real value if it
was only adopted by a handful of major ISPs and hosting providers. If
anyone wants to do this, they can probably shake $50 million out of a VC by
doing little more than wearing a black turtleneck and mumbling 'blockchain'
a lot.

We are already looking at changing the client-resolver model in DPRIV. It
is a slippery slope. They are going down it slowly and carefully, I wanted
to use skis.

2) Make [RFC6763] the preferred approach for all service discovery and
description

S. Cheshire and M. Krochmal "DNS-Based Service Discovery" RFC 6763 DOI
10.17487/RFC6763 February 2013

One corollary of this would be to admit defeat on DANE which is a dead end
for reasons that were explained 7 years ago.

RFC6763 has deployment, it is the way the home internet works today and how
all Internet services should work in the future. There should be one
mechanism to discover and describe services. That is what RFC6763 describes.

* Prefixed SRV records on the service address define the host addresses
* Prefixed TXT  records on the service address describe the service
properties
* Prefixed TXT  records on the host address describe the host properties

It is clear, logical, precise, consistent.

That TXT record is obviously the place I want to specify that clients MUST
use TLS/1.3, that they can use JSON, JSON-B or CBOR encoding, etc.

So why would I specify the TLS source of authority anywhere else?

3) Understand DNSSEC as being a mechanism to authenticate security policy
statements distributed through the DNS.

DNSSEC secures those TXT and SRV records.

Well that is how I plan to go forward at any rate. Unless someone wants to
suggest a better approach that meets my needs.

On Wed, Mar 28, 2018 at 9:41 AM, Suzanne Woolf <[email-masked]>
wrote:

> Note this discussion has started to split into (at least) two: cleaning up
> the DNS standard (protocol, documents, or both), possibly in a new WG; and
> whether/how the existing DNSOP WG needs to adjust its efforts.
>
> >> If the WG feels that the previous view of how DNSOP should work has
> been overtaken by events, we can certainly work with our Area Director (hi
> Warren!) on a revised charter.
> >
> >
> > I strongly believe that any work on cleaning up DNS protocol and/or
> rewriting RFC1034/RFC1035 and associated document would need a new WG with
> tightly defined charter.
> >
> > Hence, I will not request or I won’t support adopting my
> deprecating-obsolete-rr-types as a WG document - it might become one of the
> first documents for new WG, or it might end up as individual submission.
> While this work might be considered as “protocol maintenance”, I think it
> is bigger then simple protocol maintenance.
> >
> > Again, from experience from dnsext, I would strongly suggest that any
> work in this area is split into CHANGE documents and REWRITE documents,
> with strict scope. Documents rewriting existing RFCs while adding more
> stuff at the same time tend to not reach the finish line.
>
> I have no opinion (yet) on what the desired output should be (some new
> RFCs? A reference implementation/RFC set? Something else?), but agree it
> doesn’t fit DNSOP.
>
> Personally I think it’s within charter for DNSOP to facilitate this
> discussion, permit it to stay on the WG mailing list, etc. while people
> work out how they want to approach it, in substance and process. For
> instance, DNSOP helped get DPRIVE going by having a session at an IETF
> meeting on the DPRIVE drafts and adopting one of them (QNAME minimization).
> The important thing should be whether there’s an identifiable work item and
> whether the will exists to get it done, not how to charter a WG or
> otherwise work the process machinery. There are quite a few DNSOP (and
> IETF) regulars who are current or past WG chairs, ADs, and document
> editors, with experience of making the IETF machinery turn, who would be
> happy to advise proponents. This includes the current DNSOP chairs and AD.
>
> I do have to say I support the warnings about getting bits committed to
> documents (and possibly code). As another anecdote to add to the stack, I
> remember (as I assume Paul Vixie, Matt Larson, Rob Austein, Ed Lewis, and
> Roy Arends do) the effort it took to get the DNSSEC RFCs done: a series of
> interop workshops, a couple of open source companies sponsoring development
> in well-known code bases, and money to support production of both code and
> documents. Resources committed as an afterthought were not getting it done.
>

---

From: Jim Reid <[email-masked]>
Date: Wed, 28 Mar 2018 18:12:37 +0100

> On 28 Mar 2018, at 18:02, Phillip Hallam-Baker <[email-masked]> wrote:
> ... long rant snipped ...
> Well that is how I plan to go forward at any rate.

Good for you. Please come back to the IETF once you've figured it all out and have running, interoperable code.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Mar 2018 10:22:57 -0700

open letter.

Jim Reid wrote:
>
>> On 28 Mar 2018, at 18:02, Phillip
>> Hallam-Baker<[email-masked]>  wrote: ... long rant snipped
>> ... Well that is how I plan to go forward at any rate.
>
> Good for you. Please come back to the IETF once you've figured it all
> out and have running, interoperable code.

jim, i've been guiltier of snark than anybody else in this industry, but 
that was before i went on the beta blockers. today i'm extremely 
sensitive to it, both in myself -- and in others.

please don't answer at all, or don't cc the list, if you're going to 
snark. set the example you'd like me, and others, to follow.

thanks.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Mar 2018 11:48:41 -0700

matt, the rfc document set is innately time-series. this was seen as a 
strength compared to some "document set in the sky" that would be 
updated periodically with lineouts and additions, like for example legal 
codes or the ARIN PPML. i think you're very close to saying we need the 
latter in addition to the former, and if so, then i agree with you, but 
this is an IETF problem not a DNSOP problem. --paul

---

From: Warren Kumari <[email-masked]>
Date: Wed, 28 Mar 2018 20:56:33 +0100

On Wed, Mar 28, 2018 at 2:41 PM, Suzanne Woolf <[email-masked]> wrote:
> Personally I think it’s within charter for DNSOP to facilitate this discussion, permit it to stay on the WG mailing list, etc. while people work out how they want to approach it, in substance and process. For instance, DNSOP helped get DPRIVE going by having a session at an IETF meeting on the DPRIVE drafts and adopting one of them (QNAME minimization). The important thing should be whether there’s an identifiable work item and whether the will exists to get it done, not how to charter a WG or otherwise work the process machinery.

I fully agree -- DNSOP seems like a fine place for this discussion to
happen for now -- after some time and further discussion we can
decided if we spin up a new list to help keep discussions organized
and focused, and / or use this as a springboard to create one of more
WGs.
The new work is also likely to be a large undertaking, distinctly
unfun and grungy -- this means that we run the risk of stalling, so I
want to make sure that we have sufficient momentum and energy to make
sure the effort will succeed.

So, let's make sure we keep the discussion going, and when the chairs
feel that we are ready I'll create a mailing list for the topic and /
or discuss chartering a focused group.

> There are quite a few DNSOP (and IETF) regulars who are current or past WG chairs, ADs, and document editors, with experience of making the IETF machinery turn, who would be happy to advise proponents. This includes the current DNSOP chairs and AD.
>

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Mar 2018 11:41:30 -0400

On Wed, Mar 28, 2018 at 1:12 PM,
​​

> and have running, interoperable code.
​http://mathmesh.com/​
​https://github.com/hallambaker/Mathematical-Mesh

I always base my protocol observations on actual code. Had you actually
read my post rather than felt threatened by it, you would have seen that I
said I had code at the very start.

The sub-library in question is

https://github.com/hallambaker/Mathematical-Mesh/tree/master/Libraries/Goedel.Discovery

The discovery mechanism is described in:
http://mathmesh.com/Documents/draft-hallambaker-json-web-service.html

As I said, that is the direction I am headed in.​

Oh and since I have been in the IETF for 25 years, I take exception to folk
using exclusionary language or representing themselves as authorities on
process etc. as a way to shut down discussion of technical contributions.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Mar 2018 11:49:20 -0400

Oh and if you are going to be on a mailing list, then configure your mail
server so it does not spam people with reject notices.

---------- Forwarded message ----------
From: Mail Delivery Subsystem <[email-masked]>
Date: Thu, Mar 29, 2018 at 11:43 AM
Subject: Delivery Status Notification (Failure)
To: [email-masked]

Message not delivered
There was a problem delivering your message to [email-masked]*. See the
technical details below, or try resending in a few minutes.
The response from the remote server was:

550 5.7.1 <mail-ot0-f182.google.com[74.125.82.182]>: Client host rejected:
No thanks.

Final-Recipient: rfc822; [email-masked]
Action: failed
Status: 5.7.1
Remote-MTA: dns; mailhost.rfc1035.com. (93.186.33.42, the server for the
 domain rfc1035.com.)
Diagnostic-Code: smtp; 550 5.7.1 <mail-ot0-f182.google.com[74.125.82.182]>:
Client host rejected: No thanks.
Last-Attempt-Date: Thu, 29 Mar 2018 08:43:32 -0700 (PDT)

---------- Forwarded message ----------
From: Phillip Hallam-Baker <[email-masked]>
To: Jim Reid <[email-masked]>
Cc: dnsop WG <[email-masked]>
Bcc:
Date: Thu, 29 Mar 2018 11:41:30 -0400
Subject: Re: [DNSOP] New WG for document/protocol cleanup?

​http://mathmesh.com/​

https://github.com/hallambaker/Mathematical-Mesh/
tree/master/Libraries/Goedel.Discovery

<div class="gmail_defa ----- Message truncated -----

-- 
Website: http://hallambaker.com/

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 1 Apr 2018 02:39:06 +0530

On Wed, Mar 28, 2018 at 04:38:24AM -0400, Tim Wicinski wrote:
> to build a DNS Server (Authoritative or Resolver), what would I need to give
> them".   I also have spent a lot of time watching the 793bis work in TCPM,
> which has been moving along slowly and methodically.  I felt what we would
> come up with would be

We go through this every year or so when new staff join and we have to
train them to become expert at the DNS protocol, to handle every type of
user problem that shows up.

I think RFCs from [1033, 1034, 1035] need a rewrite. It is filled with a
world that was current in 1987, but isn't the same today. They predate
BCP 14 and have casual language that cannot be so ambiguous for such an
important protocol.

I've been looking at what Bert has been doing which is friendly and good
material, but in my head, the RFCs' rewrite would be quite different.
They'd have to be redone with a different structure, starting with the
domain name tree (3.1 of RFC 1034) and incorporating parts of 1035 right
away, getting details pedantically right. They'd need to not contain so
much prose, but specification of what DNS is.

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.

		Mukund

---

From: Matthew Pounsett <[email-masked]>
Date: Sat, 31 Mar 2018 17:20:13 -0400

On 28 March 2018 at 14:48, Paul Vixie <[email-masked]> wrote:

> strength compared to some "document set in the sky" that would be updated
> periodically with lineouts and additions, like for example legal codes or
> the ARIN PPML. i think you're very close to saying we need the latter in
> addition to the former, and if so, then i agree with you, but this is an
> IETF problem not a DNSOP problem. --paul
>

I think the RFC series as a whole needs to contain both, but I'm not saying
that both should exist simultaneously for any given set of documents within
the RFC series.  I think we've reached a point where the time series for
DNS has become so complex and convoluted that it's time for a reset to make
it readable again.  We can then carry on patching that with time-series
documents if we want, but the rewrite will give us a new baseline that's
coherent and complete, which we don't have today.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 31 Mar 2018 14:27:17 -0700

Matthew Pounsett wrote:
>
>
> On 28 March 2018 at 14:48, Paul Vixie <[email-masked]
>     matt, the rfc document set is innately time-series. this was seen as
>     a strength compared to some "document set in the sky" that would be
>     updated periodically with lineouts and additions, like for example
>     legal codes or the ARIN PPML. i think you're very close to saying we
>     need the latter in addition to the former, and if so, then i agree
>     with you, but this is an IETF problem not a DNSOP problem. --paul
>
>
> I think the RFC series as a whole needs to contain both, but I'm not
> saying that both should exist simultaneously for any given set of
> documents within the RFC series.

i think you are.

> I think we've reached a point where the time series for DNS has
> become so complex and convoluted that it's time for a reset to make
> it readable again.  We can then carry on patching that with
> time-series documents if we want, but the rewrite will give us a new
> baseline that's coherent and complete, which we don't have today.

there's a carrier wave in that time series, which has its own wave form. 
at the end of each epoch, we'll be back where we are today, without a 
coherent or complete document set. we'd be moving from failing to plan, 
to planning to fail. let's make a better move.

to achieve the goals you stated earlier, there would have to be both the 
time series of changes, and the timeless document full of lineouts. 
bert's "DNS Illustrated" github site is an example of the latter, and a 
starting point for it, if we wish.

-- 
P Vixie

---

From: bert hubert <[email-masked]>
Date: Sat, 31 Mar 2018 23:34:29 +0200

> 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?)

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?

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'm not sure what to make of this but over 25000 unique IP addresses visited
the site (for around 40000 page views) after it was listed on 'Hacker News'.
Perhaps there is some pent-up demand?

	Bert

---

From: Matthew Pounsett <[email-masked]>
Date: Sat, 31 Mar 2018 17:41:47 -0400

>> documents within the RFC series.

I'm really not.

> coherent or complete document set. we'd be moving from failing to plan, to
> planning to fail. let's make a better move.
>

That's a pretty cynical view.  Do you not think the specifications being
written today are better than they used to be?

> time series of changes, and the timeless document full of lineouts. bert's
> "DNS Illustrated" github site is an example of the latter, and a starting
> point for it, if we wish.

If we had a better baseline, and if our Updates documents were clearer
about what they change in older documents, that line-out would be a pretty
trivial document to maintain, and might not even be necessary.

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 1 Apr 2018 05:04:19 +0530

> 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.

> 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.

> 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

---

From: Michael Casadevall <[email-masked]>
Date: Sat, 31 Mar 2018 21:30:34 -0400

> "core" DNS in the same grouping as master files.

Just offhand, IPv6 stuff should be merged and consolidated here too. As
memory serves, it's currently split in two different RFCs, one which is
mostly obsolete dealing with the A6 RRtype.

> for DNS anyway, and there's room for a current protocol draft that

1034bis will likely take a rather long time to complete, so there's very
much value in hello-dns between now and then.

> lot of editing things into place.

Looked at the repo, and it doesn't look like it's committed yet. May be
worth having an open bug tracker item identicating what from what RFC is
currently in progress, etc. Once you've got this started, I'd like to
contribute to this work.
Michael

---

From: Paul Vixie <[email-masked]>
Date: Sat, 31 Mar 2018 19:02:29 -0700

Matthew Pounsett wrote:
>     there's a carrier wave in that time series, which has its own wave
>     form. at the end of each epoch, we'll be back where we are today,
>     without a coherent or complete document set. we'd be moving from
>     failing to plan, to planning to fail. let's make a better move.
>

mine have gotten better, but are still not as good as 1033, 1034, and 
1035 were. i won't speak to my perception of the quality of others' 
work. however, i have noticed that each DNS-related IETF WG has had 
times of high process discipline and times of expediency -- and i think 
that's because we're doing it with humans, and i know that we will 
continue to do this with humans. i don't experience this as cynicism.

>     to achieve the goals you stated earlier, there would have to be both
>     the time series of changes, and the timeless document full of
>     lineouts. bert's "DNS Illustrated" github site is an example of the
>     latter, and a starting point for it, if we wish.
>
> about what they change in older documents, that line-out would be a
> pretty trivial document to maintain, and might not even be necessary.

that supposition depends on what the future DNS-related WG's are, who 
chairs them, who attends meetings, what the culture is, who the AD's 
are, who the rest of the IESG and IAB are... many things we cannot 
predict now and will not be able to control then.

furthermore, the IETF would have to update some STD document every time 
a new DNS-related RFC was published, just to enumerate the full set of 
things a new implementer should study and consider. that STD could be 
just a list of RFC's, or could mention specific sections and say they 
are "in" or "out", or could repeat the relevant text. i could argue for 
any of those three approaches. but your model requires one of those, or 
else, "read them all and let the market sort it out" is our guidance to 
new implementers. that's what's not working now, and won't work, ever.

-- 
P Vixie