Note: This page is still under construction and will be updated with new results and information.

DNS Traffic Modeling

DNS traffic analysis and modeling is a complex subject in its own right, so this is an attempt to provide a brief overview of how different DNS traffic streams may be affected by DNSSEC. How DNSSEC affects what a name server sees and the resources needed depends on the zones that name server has stored.

The two factors in determining how DNSSEC would affect a name server's traffic pattern are the zones that it servers and the make up of those zones. The traffic that a root or gTLD server sees is different than the traffic a small college or corporation sees. Likewise, if an enterprise has a very popular domain name (for example, time.nist.gov. is queried by many Network Time Protocol clients), sees a different traffic makeup from other similar sized enterprise zones. When DNSSEC is added, both positive and negative responses will be larger, which will cause an increase in the bandwidth used by the DNS protocol. In DNSSEC, proof- of-non-existence responses are larger than traditional DNS negative responses due to the inclusion of NSEC RRs rather than just an error signaled in the RCODE of a response.

Traffic Load at Different Zones in the DNS

The query load and makeup a name server sees primarily depends on the zones it servers and "where" in the domain tree those zones are located. It would be impossible to say every zone at a certain level sees the same traffic, but some general observations of certain levels can be made. There are many previous works on analysis of traffic seen at the root, gTLD's, and some specific enterprise zones. These include:

For the purposes of the bandwidth experiments conducted at NIST, it was assumed that the zone being queried was an enterprise zone (university, large company, or agency). The query rate was changed, but the query breakdown remained relatively the same. The query type breakdown below is similar to the traffic query distribution found by other researchers at The Measurement Factory and this related work of performance measurements at John Hopkins University.

Query Type

Percentage (%)

Non-assigned Type

20

A

55

MX

6

SOA

12

ANY

7

In the above distribution "Non-assigned Type" means any RR type number that has not been assigned by IANA. These are usually private queries or malformed queries sent to a name server by mistake. The rest are valid data types. In addition to the query type (qtype) distribution, there is also the distribution of valid answers to name error responses. Name error responses are when the queried name does not exist in the zone, and the server is authoritative for the zone - in other words, the queried for name (qname) does not exist in the DNS. Traditionally, in DNS an error code in the message header indicates that the query is a name error. With DNSSEC, that now includes a set of (signed) records to prove non-existence of qname and/or qtype. This means negative responses will be larger as well as positive responses. In the experiments conducted at NIST, the percentage of queries resulting in name errors was 10%-20% of the total number of queries (for the base), unless otherwise noted.

DNSSEC Enabled Queries and DNS Traffic

Even with the early stages of deployment of DNSSEC, there is measurable amount of DNS traffic that requests DNSSEC signed responses. Information on how much global traffic is DNSSEC enabled is sparse, but one white paper from NLNet Labs has some preliminary findings.

Overall, the number of DNSSEC enabled queries is a fraction of the total queries the zone sees, but remains relatively constant regardless of total query volume. This was even seen before some zones were signed.

One other interesting observation in the above report is that many of the queries that did request DNSSEC signed responses did not indicate larger message sizes. In traditional DNS, message packets are limited to 512 bytes. In DNSSEC, responses are larger in size because of digital signatures included in the response. However, many of the observed queries still indicated they could only accept DNS messages 512 byes or smaller, which lead to some truncated response.

Possible Impact of DNSSEC on DNS Traffic Patterns

With the introduction of DNSSEC, names servers may experience changes to the normal traffic pattern they see. In some cases, validators will issue additional queries to different name servers to link any gaps they have when forming a validation chain. This would be noticeable in an increase in overall queries, with most of the new queries being for the DNSKEY RR for the zone.

This will be more noticeable for zones that have a particularly popular hostname (such as a web server). For example, nist.gov has a very popular hostname for its NTP service (time.nist.gov.). Most hosts will be querying for this name on startup, and most likely will not have the nist.gov zone key to validate the signatures covering the time.nist.gov address resource record. This means NIST name servers will see an increased query load on their authoritative servers as validators query for the nist.gov key in order to build a chain of trust. Caching may reduce this number, but not by very much, as any client that does not already have the time.nist.gov address cached is not likely to have the nist.gov zone key cached.

The impact on the traffic load to TLD's when DNSSEC is widely deployed is not currently understood. TLD servers will see an increase in traffic like other zones, but it is not know how much caching may reduce this amount. Large ISP's and even recursive caching servers at large corporations/universities will query for the DNSKEY of a TLD once, but then have it available in cache (for as long as the Time-To-Live (TTL) is set) for other client queries (even unrelated names that only share a common TLD).

Questions or comments should be sent to proj-dnssec@antd.nist.gov