> 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?
>> 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?
DNS mostly has to support larger sizes, and has for decades for things like svc/txt records used for various encryption and large blocks of text. Having worked for a registrar and dealing with ddos, not much you can do but filter more intelligently. There are ddos appliances/services built just to deal with volumetric queries from hosts for such reason.
Just to add real quick: there is not in fact a meaningful growing deployment of DNSSEC --- in fact, in North America and the western commercial Internet, the opposite thing is true: the number of signed zones has decreased. This is especially stark if you look at the true figure of merit, DNSSEC deployment on popular zones (take the Tranco academic research ranking of popular zones as a model):
> Yes, but doesn't IPv6 also increase the "maximum safe UDP packet size" from 512 bytes to 1280?
Sure would be nice if people used IPv6. Even if you're actually sending data over IPv6, that doesn't mean the DNS lookups are going over IPv6. Infrastructure like that lags.
> 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.
... probably because the people who originally designed DNSSEC (and DNS) couldn't believe that people would be crazy enough to try to keep their DNS records secret (or run split address spaces, for that matter). But anyway, whatever the reason, the replies are big and that has to be dealt with.
> Fair enough but are network clients actually meant to use DNSSEC?
You should be validating as close to the point of use as possible.
> Isn't this just an issue for authoritative and recursive DNSSEC resolvers to and down the roots?
If by "resolvers" you mean "local resolution-only servers", then that's common, but arguably bad, practice.
Anyway, using TCP also neuters DNS as a DoS amplifier, at least if you can make it universal enough to avoid downgrade attacks.
> probably because the people who originally designed DNSSEC (and DNS) couldn't believe that people would be crazy enough to try to keep their DNS records secret
I wonder if it's time to just retire this mechanism. In 2025 you'd have to be crazy to not use encryption with an internet-facing host, which in practice usually means TLS, which means your hostname is already logged in Certificate Transparency logs and trivially enumerated.
> couldn't believe that people would be crazy enough to try to keep their DNS records secret
You'd hope people working on DNS would have had broader actual experience with it. There was an ironic lack of paranoia in the DNSSEC people and they seemed overly focused on one peculiar problem, which is, it's easy to spoof DNS responses when you typically only have at most 2**16 - 1024 ports to choose from. They sort of ignored everything else.
> If by "resolvers" you mean "local resolution-only servers", then that's common, but arguably bad, practice.
I haven't kept pace with DNSSEC, but originally, this was the _recommended_ configuration. Has that changed?
> Anyway, using TCP also neuters DNS as a DoS amplifier,
We're ensuring all servers support TCP, but we're not anywhere near dropping UDP.
They did recommend it at one point. But I don't think that makes it not-bad. It was long enough ago that they might have been worried about crypto performance; I don't know.
> Fair enough but are network clients actually meant to use DNSSEC?
I dream of an alternate reality where DNSSEC and DANE had become more ubiquitous, and we didn't have need for CAs to sign TLS certificates[1]. But that requires DNSSEC (or some other cryptographic verification) on the client.
[1]: Or something like that. In that mythical world maybe DNSSEC was also better designed...
I would like to see DNS servers require each client to establish one TCP connection to be allowed to use UDP thereafter.
If this were the default on DNS servers, then DNS amplification attacks would be nearly impossible. They rely on spoofing a DNS request from the victim, and amplify because the response may be many times larger than the request. If TCP were required to be used before UDP responses can be received, then the victim would have to be first tricked into making a DNS request over TCP to each public DNS server.
The DNS Cookies standard (RFC 7873) doesn't do much to stop this, since it is impractical to fail queries from non-cookie clients.
DNS over TCP is supposed to be supported, so implementing this will push firewall admins in the right direction (allow both TCP/UDP outbound on 53).
That's an interesting argument, given the whole impetus behind pushing for DoT vs. DoH was to allow network administrators the discretion to block encrypted DNS (by blocking DoT).
If the DNS server is actually local like it's supposed to be, it should have just a few ms ping. Quadrupling that just once is no big deal. The user won't even notice, since every OS does lots of background DNS activity before the user even opens an app or browser.
Saying that 2xRTT is a deal-breaker is like saying TCP in general is a deal breaker.
State per client is pretty simple. Use a bloom filter to decide if a client IP is ok for UDP, and slowly set bits to zero at random to force gradual eviction. With a secret nonce per server, the attacker can't engineer collisions except by controlling lots of IPs. For IPv6, just treat blocks above a certain size (e.g. a /48) as equivalent.
And again, this should be the default. Someone that is seriously trying to run an open resolver should have their own fork of the source code and adjust this as they need. The small-time operators that accidentally make their resolvers open won't notice a bloom filter or a slow initial lookup.
> 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?
>> 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?
DNS mostly has to support larger sizes, and has for decades for things like svc/txt records used for various encryption and large blocks of text. Having worked for a registrar and dealing with ddos, not much you can do but filter more intelligently. There are ddos appliances/services built just to deal with volumetric queries from hosts for such reason.
Just to add real quick: there is not in fact a meaningful growing deployment of DNSSEC --- in fact, in North America and the western commercial Internet, the opposite thing is true: the number of signed zones has decreased. This is especially stark if you look at the true figure of merit, DNSSEC deployment on popular zones (take the Tranco academic research ranking of popular zones as a model):
https://dnssecmenot.fly.dev/
> Yes, but doesn't IPv6 also increase the "maximum safe UDP packet size" from 512 bytes to 1280?
Sure would be nice if people used IPv6. Even if you're actually sending data over IPv6, that doesn't mean the DNS lookups are going over IPv6. Infrastructure like that lags.
> 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.
... probably because the people who originally designed DNSSEC (and DNS) couldn't believe that people would be crazy enough to try to keep their DNS records secret (or run split address spaces, for that matter). But anyway, whatever the reason, the replies are big and that has to be dealt with.
> Fair enough but are network clients actually meant to use DNSSEC?
You should be validating as close to the point of use as possible.
> Isn't this just an issue for authoritative and recursive DNSSEC resolvers to and down the roots?
If by "resolvers" you mean "local resolution-only servers", then that's common, but arguably bad, practice.
Anyway, using TCP also neuters DNS as a DoS amplifier, at least if you can make it universal enough to avoid downgrade attacks.
> probably because the people who originally designed DNSSEC (and DNS) couldn't believe that people would be crazy enough to try to keep their DNS records secret
I wonder if it's time to just retire this mechanism. In 2025 you'd have to be crazy to not use encryption with an internet-facing host, which in practice usually means TLS, which means your hostname is already logged in Certificate Transparency logs and trivially enumerated.
You can work with wildcard certs and your hostnames need not be enumerated.
How is giving every internal host a wildcard cert not a cure far worse than the disease in 99 percent of the cases?
> couldn't believe that people would be crazy enough to try to keep their DNS records secret
You'd hope people working on DNS would have had broader actual experience with it. There was an ironic lack of paranoia in the DNSSEC people and they seemed overly focused on one peculiar problem, which is, it's easy to spoof DNS responses when you typically only have at most 2**16 - 1024 ports to choose from. They sort of ignored everything else.
> If by "resolvers" you mean "local resolution-only servers", then that's common, but arguably bad, practice.
I haven't kept pace with DNSSEC, but originally, this was the _recommended_ configuration. Has that changed?
> Anyway, using TCP also neuters DNS as a DoS amplifier,
We're ensuring all servers support TCP, but we're not anywhere near dropping UDP.
They did recommend it at one point. But I don't think that makes it not-bad. It was long enough ago that they might have been worried about crypto performance; I don't know.
> Fair enough but are network clients actually meant to use DNSSEC?
I dream of an alternate reality where DNSSEC and DANE had become more ubiquitous, and we didn't have need for CAs to sign TLS certificates[1]. But that requires DNSSEC (or some other cryptographic verification) on the client.
[1]: Or something like that. In that mythical world maybe DNSSEC was also better designed...
Why would that be better?
I would like to see DNS servers require each client to establish one TCP connection to be allowed to use UDP thereafter.
If this were the default on DNS servers, then DNS amplification attacks would be nearly impossible. They rely on spoofing a DNS request from the victim, and amplify because the response may be many times larger than the request. If TCP were required to be used before UDP responses can be received, then the victim would have to be first tricked into making a DNS request over TCP to each public DNS server.
The DNS Cookies standard (RFC 7873) doesn't do much to stop this, since it is impractical to fail queries from non-cookie clients.
DNS over TCP is supposed to be supported, so implementing this will push firewall admins in the right direction (allow both TCP/UDP outbound on 53).
That's an interesting argument, given the whole impetus behind pushing for DoT vs. DoH was to allow network administrators the discretion to block encrypted DNS (by blocking DoT).
quadrupling first query time wouldn't be acceptable. And now server have to keep some state per client so more requirements
If the DNS server is actually local like it's supposed to be, it should have just a few ms ping. Quadrupling that just once is no big deal. The user won't even notice, since every OS does lots of background DNS activity before the user even opens an app or browser.
Saying that 2xRTT is a deal-breaker is like saying TCP in general is a deal breaker.
State per client is pretty simple. Use a bloom filter to decide if a client IP is ok for UDP, and slowly set bits to zero at random to force gradual eviction. With a secret nonce per server, the attacker can't engineer collisions except by controlling lots of IPs. For IPv6, just treat blocks above a certain size (e.g. a /48) as equivalent.
And again, this should be the default. Someone that is seriously trying to run an open resolver should have their own fork of the source code and adjust this as they need. The small-time operators that accidentally make their resolvers open won't notice a bloom filter or a slow initial lookup.
Why not just split responses over multiple UDP packets?
Spoofing/amplification attacks are already a problem, no?
[March 2016]
Important note because DoT deployment has basically collapsed compared to DoH, which appears to have won the market.