Evaluation of Future DNSSEC Response Sizes at a Root and a TLD Server

Liang Zhu, Zi Hu and John Heidemann / 2015-01-22

TL;DR: A root trace suggests there is minimum (almost no) risk to go to 2048-bit ZSK and 2048-bit KSK for root server. A TLD trace shows 5.5% DNSSEC enabled responses getting IPv4 fragmented with 2048-bit ZSK and more with longer keys. We suggest TLD and other authoritative server operators analyze their server's response traffic and inform their customers of possible problems before moving to use longer keys.

Problem Statement

There have been repeated questions about how big DNSSEC keys should be. The concern is that larger keys will cause IPv4 fragmentation of replies to become frequent.

This page summarizes analysis of trace data from a root server (B-Root) and a TLD server (.com) to estimate the effects of different DNSSEC key sizes on the size of DNS responses. Root DNS servers sit at the top of the DNS hierarchy and so are of particular concern, and .com is one of the largest TLDs.

DNSSEC has two keys: a Zone Signing Key (ZSK) that is used to sign DNS records (except for DNSKEY records) in the zone, and a Key Signing Key (KSK) that is used just to sign the DNSKEY records. Several factors affect reply sizes:

• Sizes of replies for non-DNSKEY queries are affected by the size of the ZSK and the query string.
• Sizes of replies for requests for the DNSKEYs are affected by ZSK and KSK sizes.
• Sizes of replies for requests for the DNSKEYs during key rollover are affected by ZSK and both the new and old KSK sizes.

IPv4 fragmentation is a concern because fragmented replies have poor performance when packet loss is high because packet loss of any fragment requires timeout and retransmission of the whole message. Also, some firewalls discard fragments, so replies that are fragmented may never be received, DNS over TCP can work around problems caused by fragments.

As of today (Jan 22, 2015), the most common ZSK sizes in use are 1024 bits and KSK is 2048 bits.

There was a discussion about the suspected weakness of 1024 bits ZSK in DNS community. Some DNS operators are considering moving to larger key sizes, such as 2048 bits ZSK.

What are Possible Future DNSSEC Response Sizes at a Root server?

Here we consider RSA-based signatures for DNSSEC. Other algorithms, like ECDSA, are attractive because it has much smaller signatures. However, while standardized, there are concerns that ECDSA is not nearly as widely deployed, and resolvers will ignore algorithms they do not understand, loosing the benefit of DNSSEC.

We estimate DNSSEC response sizes with different key sizes using DNS traffic at B root using a hour-long long trace of 31M DNSSEC-enabled responses. We find that

ZSK size	packets larger than 1500 bytes
1024	None
2048	<0.005%
3072	~5.6%
4096	~40%

More details results are shown in the figure below. We show NXD responses particularly because NSEC and NSEC3 could make large packets. We only show the median for NXD responses since the quartiles are close to median.

The bottom line is that the conditions marked with X below cause IPv4 fragmentation, particularly for DNSKEY responses.

		KSK (normal)
		2048	3072	4096
ZSK	1024	-	-	-
	2048	-	-	-
	3072	-	-	X
	4096	-	-	X

		KSK (rollover)
		2048	3072	4096
ZSK	1024	-	X	X
	2048	-	X	X
	3072	X	X	X
	4096	X	X	X

This data suggests that there is minimum (almost no) risk to go to 2k ZSK and 2k KSK, even during KSK key rollover. One might wish to go to 2k ZSK and 3k KSK, but there may be fragmentation during KSK key rollover.

We see some fragmentation with larger key sizes, such as a 3k KSK during key rollover, or a 4k ZSK.

What are Possible Future DNSSEC Response Sizes at a TLD?

We also estimate DNSSEC response sizes with different key sizes using DNS traffic collected at one of the .com servers. We using one 10-minute trace with 13.5M DNSSEC-enabled responses. Although this trace is short, we believe it is long enough to be representative.

We find that

ZSK size	packets larger than 1500 bytes
1024	None
2048	~5.5%
3072	~18.5%
4096	~30.3%

Same as at Root server: DNSKEY responses are the same as that of B-Root because response size is dominated by the size of keys. (The exact packet size differs for a few bytes because of the difference between query names, com and ".".)

Different from B-Root

NXD responses start to get IPv4 fragmentation with 2048-bit ZSK for .com, while 4096-bit ZSK for B-Root.

There are more packets getting IPv4 fragmentation at .com with than B-Root with the same size of key. This is because .com responses are often longer than root responses.

Bottom line: a 2k ZSK will have some IPv4 fragmentation in replies. To the degree that fragmentation impedes resolution of certain names (typically because of overly strict middleboxes), this analysis suggests use of TCP for such queries, or resolution of middlebox problems, will be required. Further investigation is required to understand how often middleboxes are overly strict, and if TCP will operate (as required by RFC) where overly strict middleboxes cause problems.

How Do We Estimate?

This analysis and the TLD data are both derived from prior work released as the technical report "T-DNS: Connection-Oriented DNS to Improve Privacy and Security (extended)", by Zhu, Hu, Heidemann, Wessels and Mankin.

Estimate: What changes and how

With different sizes of keys, the only thing changed in a DNSSEC response is the sizes of RRSIG resource records.

There are various of DNSSEC Algorithms, in which there are four major groups: RSA, DSA, GOST and ECDSA.

RSA/SHA-X
RSA is used with hash functions. Since the result of SHA-X won't be larger than current ZSK size (1024 bits) and RSA will do padding, the signature size is the same as key size. Our estimation is based on this algorithm since it's more commonly used for DNSSEC although other algorithms result in smaller packet sizes (less likely to cause larger packets).

DSA/SHA-1
According to 6.2.8 DSA with SHA-1 (Table 21) of PKCS #11 V2.30 mechanisms part 1, the signature size is 40 bytes (fixed). Note that, according to RFC6781, "in the context of DNSSEC, DSA is limited to a maximum of 1024-bit keys."

GOST R 34.10-2001
From section 5 Deployment Considerations of RFC5933, the signature size is is 512 bits.

ECDSA
According to Crypto++ Library, the signature size of ECDSA/P-256 is 64 bytes, and that of ECDSA/P-384 is 96 bytes.

Estimate: Analysis of real data

We analyzed DNS traffic captured at B-Root and one of .com servers by replacing current 1024-bit RSA signature with longer ones.

The B-Root DNS trace was captured roughly from 12:03 to 13:10 on 2014-04-29, and it contains 31.1M DNSSEC enabled responses. The .com DNS trace is 10-minute and was captured in July 2014, with 13.5M DNSSEC enabled responses.

To generate the estimated sizes of all DNSSEC responses,

	for $size of all DNSSEC responses without TC bit set (not truncated)
	  get number of RRSIG records $num_rrsig
	  for $zsk in (1024, 2048, 3072, 4096)
	    $add = $zsk/8 - 128 (current ZSK size)
	    $est_size = $size + $add * $num_rrsig
      

To study the DNSKEY response sizes,

	get current DNSKEY response size (including IP and UDP headers) $BASE
	$BASE = $BASE - 128 (current ZSK size) - 256 (current KSK size) - 256 (current RRSIG size)
	for different $zsk in (1024, 2048, 3072, 4096) and different $ksk in (2048, 3072, 4096)
	  $z1k1 = $BASE + $zsk/8     + $ksk/8     + $ksk/8      // 1 zsk, 1 ksk
	  $z1k2 = $BASE + $zsk/8     + $ksk/8 * 2 + $ksk/8 * 2  // 1 zsk, 2 ksk (ksk rollover)
      

Comments

We welcome comments about this work.