Categories
IETF Internet

DNSSEC and large packets

In the wake of .org going signed, we finally have good data what that means for the authoritative nameservers. Duane gave a good talk at the recent NANOG event, showing the increase of TCP connections.

So what is the problem?

In a nutshell: Packet sizes. DNS responses containing the DNSSEC specific RRSETs are larger, and setting the DO bit that triggers their inclusion is almost default these days. So we’re now routinely exceeding the 512 bytes that the original DNS spec required. Over the years, the IETF defined EDNS0 which allowed clients to announce their support for larger responses via UDP. Not this is finally really put to the test and we can see how fallback to TCP we still observe.

The factor 600 more TCP for the .org nameserver raised quite a number of eyebrows. Discussions on why and what could be done about that erupted on a number of mailinglists (e.g namedroppers).

Anyway, I wanted to test the packet sizes myself so here are some hints on how to look at these issues. First of all, you should get a current copy of dig that understands the NSEC3 record. With that:

Find a .org nameserver:

$ dig NS org.
[...]
;; ANSWER SECTION:
org. 86400 IN NS b2.org.afilias-nst.org.

To get the answer-size of a typical query, we do e.g.

$ dig A www.isc.org. @b2.org.afilias-nst.org. +dnssec +norec
[...]
;; Query time: 125 msec
;; SERVER: 2001:500:48::1#53(2001:500:48::1)
;; WHEN: Mon Jun 22 13:30:42 2009
;; MSG SIZE rcvd: 685

and just look at the MSG SIZE field. The 685 here basically means that EDNS0 needs to work, or we’d be going TCP already.

Okay, let’s compare answer sizes for other cases (NXDOMAIN, signed delegation):

$ dig A www.iscfoo.org. @b2.org.afilias-nst.org. +dnssec +norec
[...]
;; Query time: 109 msec
;; SERVER: 2001:500:48::1#53(2001:500:48::1)
;; WHEN: Mon Jun 22 13:38:03 2009
;; MSG SIZE rcvd: 1008

Well, I could not find a signed .org delegation, thus I used one in .gov:

$ dig A www.dotgov.gov. @G.GOV.ZONEEDIT.COM. +dnssec +norec
[...]
;; Query time: 164 msec
;; SERVER: 76.74.254.208#53(76.74.254.208)
;; WHEN: Mon Jun 22 13:46:13 2009
;; MSG SIZE rcvd: 440

To summarize:

Delegation to signed zone: ~ 440 Bytes
Delegation to unsigned zone: ~ 685 Bytes
NXDOMAIN: ~ 1008 bytes

As Peter Koch put it succinctly:

That means, at least for an NSEC3 signed zone, DO=1@512 is asking for TC.

—————-

Two other comments: While looking for a signed .gov zone, google showed documents on www.dotgov.gov that sounded promising but I couldn’t contact their web-server. Then I just checked their delegation status and saw the DS records. Well, as I’m using a validating resolver at the office my first guess was that I ran into a signature validation error, but it turned out that both nameservers for dotgov.gov are offline.

This is not a common occurrence in plain DNS, so I’m wondering whether perhaps the zone-signing process of their provider messed up. If yes, then this is exactly one of the problems I raised in my recent talk.

[Update: I asked around and apparently, dotgov.gov does some heavy filtering of the nameservers and webservers based on the country of origin of the request. Sheeesh.]

Furthermore, bonus points to all readers who noticed that some of my queries used IPv6 transport 🙂