Bandwidth usage in Zone Transfers

Increase in zone size also means larger zone transfer transactions between primary and secodary authoritative servers. This may lead to a sizable increase in bandwidth usage if the zone is fairly large and transferred frequently. The table below shows some numbers for the zones that are used in the zone size growth study. In the table, the signed zone transfer are signed using a single 1024 bit RSA/SHA-1 key:

For 1 RR per owner name

For 5 RR per owner name

For 10 RR per owner name

Note that this is for a full zone transfer (AXFR transaction). For servers that use incremental zone transfers (IXFR), this may not be a major issue except for cases when a large number of changes are made (re-signing for example).

Bandwith Usage for DNSSEC vs. DNS Responses

It is known that deploying DNSSEC will result in an increase in bandwidth used by DNS for a given zone. The impact will depend on two main factors - the normal traffic load on a given server, and how many incoming requests ask for DNSSEC records to be returned. DNS traffic modeling can be a very detailed topic worthy of it's own discussion, including some info of the traffic used for the analysis below. Note that in the numbers below, all packet headers are included in the bandwidth usage.

Discussion

The biggest impact that will be visible to all DNSSEC users will be in bandwidth consumption. Not just in positive responses (inclusion of RRSIGs) but negative responses as well (proof of non-existence).

In the above examples, the same traffic traces were run using no DNSSEC-enabled queries, with 50% DNSSEC-enabled queries, and with 90% DNSSEC-enabled queries. 90% of all queries requesting DNSSEC is admittly a blue-sky scenario (or worst-case when it comes to bandwidth consumption). In the immediate future, even 50% of all queries requesting DNSSEC responses could be seen as overly optimistic. See this discussion on the traffic trace used for a discussion on current levels of DNSSEC-enabled queries seen on the Internet

In the above scenario traces, the bandwidth usage for traces with 50% of the traffic requesting DNSSEC shows roughly 3.3 to 3.6 times the usage as the same trace with no DNSSEC. When the percentage of DNSSEC-enabled traffic reaches 90%, the bandwidth usage increases over 4.3 to 4.8 times non-DNSSEC bandwidth usage. Note that this number is also due to the contents of the zone being queried. In this case, there are three unique name servers in the additional section, so there would be three signatures in the additional section as well. If there were fewer name servers, or all the name servers shared the same name, there would be fewer RRSIG RRs in the response, and hense less bandwidth usage.

Note that these traffic simulations, the delay for the query for the DNSKEY for the zone was estimated based on previous examples. That results in slightly skewed numbers for queries/minute and the number of name error and no-error/no-data responses. However, it could be said that these error response rates will go down due to the increased number of queries for DNSKEYs - which would exist in a signed zone.

Special Note for Leaf Zones

A special note should be mentioned with regards to enterprise servers that server leaf zones (i.e., zones that contain mostly data RRs and with few delegations). As mentioned in the discussion covering DNS traffic traces, DNSSEC enabled queries will have a larger impact on bandwidth usage than just larger responses. This has to do with how a validator constructs a chain of trust. In BIND versions 9.3.1 and previous, the zone DNSKEY RRset (and associated RRSIGS) were included in the additional section of a DNS response. The RIPE NCC study on authoritative servers showed that including this data in the additional section has an adverse affect on bandwidth usage for zones high in the DNS tree (e.g., gTLD's).

Those conclusions work for delegation only zones, but the opposite may be true for some leaf zones. Recursive servers frequently query gTLD's for differnet names, and only need to get the DNSSEC information (DNSKEY RRset) once. After it is in cache, it is redundant in following query/response transactions.

For some leaf zones, it is the opposite - many clients access a zone for one (or a handfull) of domain names in a short span. This is especially true for leaf zones with a particularly popular domain name. In these cases, it may be better for the server to include the DNSKEY RRset (and RRSIGs) in a response in order to save the bandwidth that would be consumed in a second query/response. For example, consider a zone and a query for a single A RR. The zone is signed and there are two DNSKEY RRs in the DNSKEY RRset: a KSK and ZSK, both 1024 bits in size. If the name server includes the DNSKEY RR, the overall query/response takes 1100 bytes for one message transaction (DNS message sizes only, excluding the any lower protocol headers). If the DNSKEY RRset is absent in the additional section, the client must requery for it, leading to 2 query/response transactions taking a total of 1400 bytes.