In message <5C02BCCA-79D7-40A5-BFB0-26284A667E78(_at_)vpnc(_dot_)org>, Paul
Hoffman writes:
| The root name service:
|
| . . .
|
| MUST support IPv4[RFC0791] and IPv6[RFC2460] transport of DNS
| queries and responses.
This needs an addition: "Some servers in the root name service might not
support IPv4, and some might not support IPv6." Without that, some people
might think that each server must respond on both layer 3 technologies,
but they do not.
| MUST support UDP[RFC0768] and TCP[RFC0793] transport of DNS
| queries and responses.
This also needs an addition, but I am not sure what it should say. Must
every server in the service respond correctly on TCP?
Yes.
If so, what does
"correctly" mean in the anycast world that most of them live in?
It means that they respond to TCP packets they see.
| MUST generate checksums when sending UDP datagrams and MUST verify
| checksums when receiving UDP datagrams containing a non-zero
| checksum.
If "MUST verify checksums" means that if the request has a broken
checksum, the server should not reply, that needs to be explicit. If
that's the intention, better wording would be:
MUST generate checksums when sending UDP datagrams.
MUST not respond to UDP datagrams containing a
non-zero checksum if that checksum does not verify.
If that's not what was intended by "MUST verify checksums", this still
needs clarification.
| MUST answer queries from any entity conforming to [RFC1122] with a
| valid IP address.
Joe brought up this question, and it's important. Is this BCP preventing
"the root name service" from rate-limiting during DoS attacks?
| MAY also serve the root-servers.net zone, and the zone for the
| .arpa top-level domain [ARPAZONE],[RFC3172].
A "MAY" is not a requirement, and thus does not belong in this document.
The service "may" do all sorts of things that are not listed here.
--Paul Hoffman
I would also add MUST fragment IPv6 UDP at network MTU (1280). MUST
NOT send IPv6 TCP segments bigger than network MTU. Both of these
rules are to avoid triggering PMTU discovery in IPv6.
For IPv4 MUST NOT set DF.
With anycast servers the PTB response may got to the wrong instance.
The ORG servers are configured to not send IPv6 UDP EDNS responses
bigger than what will fit in a 1280 octet packet. This results in
lots of unnecessary TCP connections as the client needs to fallback
to TCP. The servers then send maximum sized TCP segments which
don't make it through tunnels and the PTB handling is marginal.
There is no need to avoid fragmenting UDP packets. If the client's
path doesn't let through fragmented packets they will adapt their
query or they will fix the path. All it does is penalise clients
which have working paths as they then need to fallback to TCP.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org