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