Re: [DNSOP] Is DNSSEC a Best Current Practice?

[Mukund Sivaraman <[e-mail]>]

On Fri, Mar 11, 2022 at 01:49:41AM -0800, Paul Vixie wrote:
> Tim Wicinski wrote on 2022-03-11 01:38:
> > ... for several years now I have
> > felt those two need to be republished with all
> > the updated text from the many updates (28 for 1035, 18 for 1034) in new
> > documents.  This does not include any other
> > changes, and it feels like a thankless task.
> not just thankless but useless. a correctness preserving rewrite, from
> scratch, should be performed every few decades. (we're overdue.) a goal
> should be readability which will require NOT reusing most of the original
> text or including the updated text. we often didn't know or otherwise
> misstated our implications. every material statement made by any prior DNS
> specification or update to the specification should be enumerated and
> checked off as its then-modern meaning is incorporated.
> 
> i'll offer to join a team to work on this when i eventually retire, if it
> hasn't been recently enough done at that time. so, i think, should other
> guilty parties.

Some years back, I tried to begin a "squash" document along these lines,
but like many other drafts, it was abandoned. When discussing it with
colleagues, most had the opinion that this was a wasteful
endeavour. Opinions were that it was too much work, that the landscape
was changing too much and a new document would become obsolete too.

https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-squash-01

I've assisted new DNS developers in the course of my work. From this
experience, there should be an effort to make a new modern document as
the details of correctly implementing DNS are scattered in too many RFCs
and drafts. It is daunting for a newcomer to navigate unless they have
read all the RFCs prior and know where to find what.

As an example, 2 weeks ago I was asked by a colleage why when parsing a
CNAME response a resolver discards the links of the CNAME chain except
for the link with the owner name it queried for (unless it can validate
the other links). The way this requirement is written in the
corresponding RFC, it's difficult to search and find the appropriate
RFC. If someone is implementing DNS functionality afresh, they may even
miss such requirements because they're all over the place.

		Mukund