EDNS Buffer Size Calculator for DNSSEC

The moment of DNSSEC‘s home-network break-in: It was a hack; that’s what the error log seemed to say. Pages wouldn’t load from the resolver. Everything we thought we knew about networking seemed to be at fault. Except it wasn’t quite so dramatic.

The problem was that a signed DNS response were larger than the UDP packet that transported it. That server sent back a signed response, setting the truncation bit in hopes of a switch to TCP. But that TCP traffic was dropped because the local firewall was old school. And silence fell.

How to Choose the Right DNS Buffer Size

You won’t escape all failures in DNS, no matter how well you get the numbers right; but you’ll sure eliminate commonest ones. The tool above handles math so you can focus on the architecture. Reliability vs Capacity That’s the main point.

You’d like your EDNS buffer big enough to hold all those new signed responses without requiring the switch to a different protocol, but you’d also like that buffer to be as small as possible so that it survives worst case scenario along the way to the server. Remember: the internet is not a clean pipe. The internet consists of layers of old firewalls, tunnels, and virtual networks. Each layer add overhead. VPNs add encryption wrappers. IPv6 headers are bigger than IPv4 ones. Even something as seemingly harmless as VLAN tagging consume space.

By allowing you to choose your own network path profile, the calculator factors these variables in. That’s where most folks go wrong. They set up their servers using the NIC speed of whatever machine they’re running them from. Then, they completely ignore longest hop down the chain.

There’s also a bit of a tradeoff between how much to advertise as a buffer. Advertise a huge one, and it risks being fragmented. Fragmented UDP packets mean death for DNS. Any single fragment gets dropped, then the whole response gets dropped. This results in timeouts, retries, and more. This feels just like a broken internet to the end user.

Advertise too small a buffer and you’re forcing a lot of TCP fallback. It’s not necessarily bad. TCP is reliable after all! But it’s heavier on the server and may be blocked by restrictive firewalls.

The challenge is finding that sweet spot, where most of your responses fits inside of UDP and those that do not fail gracefully. As you can see from the reference table on the page, the target size is 1232 bytes. That’s one reason to remember it. That figure comes from the DNS Flag Day effort. It’s the largest payload that can be sent through an IPv6 packet without fragmenting, given a minimum MTU of 1280. That’s safe as a default value for any resolver facing the Internet.

For public-facing resolvers, this is the safest default. On your own internal network or home lab where you control everything along the path, you could go higher. You can do this only if you make sure some intermediary isn’t simply discarding oversized packets (on an Ethernet link you can send bigger packets, but again do your homework first).

Each query increases the load on your server because of DNSSEC. A typical IP address lookup will return in a couple of hundred bytes. RRSIG records can double that size, and larger DNSKEY records (particularly RSA) can extend the response far above the UDP protocol’s safety margin. And that’s good! While these cryptographic signatures take up space, they make sure the response comes from who claims it does. Without them, you’d have no way of knowing you’re getting back the “right” answer. You can’t simply remove the signature without breaking its integrity and destroying the chain of trust.

By allowing you to enter an estimate of the expected response size for a given type of query, the tool shows how much room is available in the buffer. Is there enough to contain a signed reply? Or must you anticipate truncation?

Things get even more complicated when there’s a tunnel involved. Did you know that tunnels can add overhead to your queries? If your recursive resolver is inside an IPsec or WireGuard tunnel, you’ll have to account for those overhead bytes when calculating your remaining space. There are profiles for this in the calculator.

It’s possible you can use a small buffer size (e.g., 1472) on your local LAN and it’s totally fine, yet that exact same query sent across a site-to-site tunnel fails. The tool tells you clearly with its margin calculation. A positive margin simply means the response fits. Negative: Server truncates the answer and hopes your client supports TCP fallback.

DNS tuning is in the end an exercise in expectation management. You aren’t going to make the internet act like your LAN. But you can set up your gear so it works around what happens on the internet.

Test the config with the maximum response size you’re expecting. Monitor your log files for truncation flags. If you find that too much is dropping then lower the buffer. You should of increased it if you’ve confirmed the rest of the chain supports it.

The data points are important, but the context is what’s most critical. Get the buffer right and the network will stay silent even as the questions grow large.