In message <94F2C35A-95D1-41CA-9CA5-2F7D59111E0B(_at_)vpnc(_dot_)org>, Paul
Hoffman writes
:
Greetings again. These are comments on the recently-issued -02 draft.
Overall, it looks good, but there are still some issues to be addressed
before publication.
The requirements in Section 2 should be clearly stated as being
appropriate only for the authoritative name service. The last bullet says
this, but the first bullet says "MUST implement core DNS [RFC1035] and
clarifications to the DNS [RFC2181]." That could be interpreted as saying
that the root name service must follow all the rules of RFC 1035, not
just those that apply to authoritative name servers, and there are a
bunch that should not be required. Consider changing that sentence
fragment to "MUST implement core DNS [RFC1035] and clarifications to the
DNS [RFC2181], as an authoritative name service".
Another bullet in Section 2 may be problematic:
MUST generate checksums when sending UDP datagrams and MUST verify
checksums when receiving UDP datagrams containing a non-zero
checksum.
What happens if a root name server receives a UDP datagram with a bad
checksum? It fails verification, but then what?
The datagram gets dropped as bad.
This sentence *might*
incorporate the following clarification, but I'm not sure if it actually
matches the intent.
MUST generate checksums when sending UDP datagrams, and MUST
ignore a received UDP datagram containing a non-zero checksum
when that checksum does not verify.
If that's not the intent, I'm not sure what "verify" means without a
follow-on action.
Editorial:
- There are many places where spaces are missing, such as "domain name
system(DNS)" and "IPv4[RFC0791]" (there are many others).
- The first sentence of the Introduction should be changed to reflect the
fact that, when published, this document obsoletes RFC 2870. Instead of
"[RFC2870] discusses", it should say "[RFC2870] discussed".
--Paul Hoffman
What also needs to be there is a formal requirement to implement all
of EDNS (RFC6891). There are lots of TLDs that fail to do this and
this causes problems for people trying to use the extension. If TLD
operators do this today there is a chance that a root server operator
will also do this.
See http://users.isc.org/~marka/tld-report.html
Also unknown record types RFC3597 must be supported. While the
intent of RFC 1034 is that queries for unknown records get a
NOERROR/NXDOMAIN response we see a implementations returning REFUSED
and NOTIMP. Note meta query types in the reserved meta range
(RFC5395) may still get NOTIMP.
We have operational problems deploying TLSA records as some nameservers
return NOTIMP or even drop TLSA queries (scrubbing services do this
today).
The last reserved bit in the DNS header should also be ignored if
present in a query and not be present in the response. This is
implied by RFC 1034 but not formally stated. There are nameserver
implementions that will drop such queries. There are nameserver
implementions that will return FORMERR to such queries. There are
nameserver implementions that will return NOTIMP to such queries
Root nameservers should be a future proof as possible in their handling
of queries.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org