> The growing deployment of DNS Security (DNSSEC) and IPv6 has increased response sizes and therefore the use of TCP.
Yes, but doesn't IPv6 also increase the "maximum safe UDP packet size" from 512 bytes to 1280?
> Existing deployments of DNSSEC [RFC4033] have shown that truncation at the 512-byte boundary is now commonplace. For example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost invariably larger than 512 bytes.
This has been a flagged issue in DNSSEC since it was originally considered. This was a massive oversight on their part and was only added because DNSSEC originally made it quite easy to probe entire DNS trees and expose obscured RRs.
> The MTU most commonly found in the core of the Internet is around 1500 bytes, and even that limit is routinely exceeded by DNSSEC-signed responses.
> Stub resolver implementations (e.g., an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit the interoperability between their own clients and upstream servers.
Fair enough but are network clients actually meant to use DNSSEC? Isn't this just an issue for authoritative and recursive DNSSEC resolvers to and down the roots?
themafia•9m ago
Yes, but doesn't IPv6 also increase the "maximum safe UDP packet size" from 512 bytes to 1280?
> Existing deployments of DNSSEC [RFC4033] have shown that truncation at the 512-byte boundary is now commonplace. For example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost invariably larger than 512 bytes.
This has been a flagged issue in DNSSEC since it was originally considered. This was a massive oversight on their part and was only added because DNSSEC originally made it quite easy to probe entire DNS trees and expose obscured RRs.
> The MTU most commonly found in the core of the Internet is around 1500 bytes, and even that limit is routinely exceeded by DNSSEC-signed responses.
> Stub resolver implementations (e.g., an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit the interoperability between their own clients and upstream servers.
Fair enough but are network clients actually meant to use DNSSEC? Isn't this just an issue for authoritative and recursive DNSSEC resolvers to and down the roots?