DNS Survey: October 2010 Geoffrey Sisson c 2010 The Measurement Factory November 30, 2010 Abstract This study, commissioned by Infoblox, undertakes to measure the number of DNS servers on the Internet and to quantify their various DNS behaviors and configuration choices. 1 Introduction In this study we undertook to measure: • The number of name servers in use in a random 5% sample of the routed IPv4 Internet. • The configuration of zones and associated name servers in a random 1% sample of the domains in the .com, .net, and .org zones. • The implementations and versions of name server software used. • Whether recursion is supported (i.e., open resolvers). • Whether recursive name servers use predictable ports. • Whether authoritative name servers openly permit AXFR. • Whether name servers support TCP. • Configuration decisions for DNSSEC. • Whether DNSSEC-signed zones validate. • How many name servers support EDNS. • How many zones are configured for IPv6, SPF, or DKIM. • How many zones have DNS wildcards. • What SOA and TTL values are in use in a zone. • Whether information in a zone agrees with its parent. • Whether a zone has a lame name server. • Whether the TTLs of the authoritative NS RRs for a zone match. • To what degree redundant name servers are topologically diverse. • How many name servers support 0x20. • The geographic location of name servers. $Id: dns_survey_2010.tex,v 1.27 2010-12-09 22:03:29 geoff Exp $
This survey comprises results of two distinct data sets. Dataset I is a random 5% sample of therouted IPv4 Internet. Dataset II is a random 1% sample of the domains in the .com, .net, and.org zones.
2.1 Dataset I – Random IP Addresses
To obtain Dataset I, we probed a random sample of all IPv4 addresses routed on the Internet.We began with an October 2010 snapshot of the global routing table taken from the Route ViewsProject with a total of 2,126,357,495 routed IPv4 addresses.[1] We then eliminated addressesending in .0 or .2551, subnets associated with the .mil and .gov domains as well as a few subnetswhose operators had previously requested to be excluded from scans. We then randomly selected5% of the remaining IP addresses for our survey, yielding 105,497,945 IP addresses to probe.
2.2 Dataset II – Second-Level Zones in .com, .net, and .org
Dataset II contains name servers authoritative for a registered .com, .net, or .org domain. Wetreated this as a separate data set because the authoritative name servers are assumed to be morestable over time, better maintained, and more heavily used on average than randomly discoveredname servers. Furthermore, this data set is used to study the adoption of new technologies inthe DNS, namely IPv6, DNSSEC, DKIM, and SPF. We obtained zone files from VeriSign andPublic Interest Registry (PIR) for .com, .net, and .org containing 90 million, 13.4 million, and8.6 million domains respectively, and randomly selected 1% (1,122,518) to probe.
3 Results for Dataset I
3.1 Number of Name Servers
We sent a simple DNS query to each address in Dataset I asking for the IPv4 address fora.root-servers.net and with the RD bit set. A DNS response of any type (including SERV-FAIL) was taken to indicate the presence of a DNS server. We did not implement timeouts andretransmissions, so the results are subject to packet loss; however the amount of packet loss isbelieved to be small, and to have had negligible impact on the results.
Table 1 summarizes the number of queries and replies.
Note that some addresses sent back more than one reply, even though we sent only one query.This occurs either because the probe address actually sends multiple responses for a single query,
1While these can be valid host addresses, in practice they are infrequently assigned.
2
or because the reply source address may be different than the query destination address.2 Of thereplying hosts, 23,738 (3.1%) were ones to which we never sent a query. This is in part attributableto network operators who intercept incoming DNS queries and forward them on to other hosts,which then respond using their own addresses.
Based on these figures we estimate that there are approximately 15,553,600 name servers onthe Internet. This is a drop of 746,400 (4.6%) from last year’s estimate of 16,300,000, in spiteof the fact that 1,1131,893 (11.7%) more addresses were probed this year.
4 Name Server Software Versions
For each name server found in both data sets, we attempted to determine the name server softwareand version using a combination of two techniques. First, we used fpdns to fingerprint the server.[2]This typically results in a range classification of possible versions, for example “BIND 8.3.0-RC1– 8.4.4”. Second, we sent a “version.bind” query to the server to refine the fpdns result if andonly if the version reported by version.bind fell in the range of possible versions as determined byfpdns. While we could have used version.bind queries alone, many name servers are configured toreport an obfuscated result or no result at all.
Note that there are limitations to this approach:
• fpdns differentiates between implementations on a best-effort basis. Two implementationscan look identical to fpdns and there may be no way to distinguish between them.
• fpdns has not been actively maintained in recent years.
• Even had fpdns been maintained, there has been a proliferation of commodity routers,firewalls and other “middleboxes” with no-name or proprietary DNS implementations thatwould be difficult to track.
As a consequence, the survey results contain false positive and false negative identifications, andshould be interpreted with caution.
2In a few cases, large numbers of replies were sent from what could be described as “DNS bombs”: hosts thatappeared to be designed to send an unending stream of replies to the source address of a query. We suspect thatthese are malware-infected hosts intended for use in DDoS attacks.
3
4 NAME SERVER SOFTWARE VERSIONS
Figures 1, 2, and 3 summarize the distribution of name server software versions for Dataset I.
0
50
100
150
200
250
300
BIN
D
Nom
inum
CN
S
Ver
mic
elli
totd
robt
ex V
ikin
gD
NS
mod
ule
Mik
rotik
dsl
/cab
le
Rai
den
DN
SD
Ver
iSig
n A
TLA
S
DJ
Ber
nste
inT
inyD
NS
Alte
on A
CE
switc
h
AT
OS
Sta
rgat
e A
DS
L
Mic
roso
ft D
NS
(Win
dow
s 20
00)
bboy
MyD
NS
JHS
OF
Tsi
mpl
e D
NS
plu
s
Cis
co C
NR
Mic
roso
ft D
NS
(Win
dow
s 20
03)
NLn
etLa
bs N
SD
Max
Feo
ktis
tov
smal
l HT
TP
ser
ver
shee
rdns
(oth
er)
(tim
e ou
t)
(no
mat
ch)
Nam
e S
erve
rs (
thou
sand
s)
266,227(34.2%)
93,345(12.0%)
43,064(5.5%)
19,012(2.4%)
17,206(2.2%) 5,059
(0.7%)
4,238(0.5%)
3,548(0.5%)
2,388(0.3%)
2,344(0.3%)
2,103(0.3%)
1,858(0.2%)
611(0.1%)
465(0.1%)
421(0.1%)
310(<0.1%)
302(<0.1%)
284(<0.1%)
1,798(0.2%)
37,469(4.8%)
275,628(35.4%)
Figure 1: Distribution of name server software versions – Dataset I.
4
0
50
100
150
200
250
300
BIND4.8 −4.8.3
BIND4.9.3 −4.9.11
BIND8.1-REL −
8.2.1
BIND8.2.2-P3 −8.3.0-T2A
BIND8.3.0-RC1 −
8.4.7-P1
BIND9.0.0b5 −
9.0.1
BIND9.1.0 −
9.2.0rc3
BIND9.2.0a1 −9.2.2-P3
BIND9.2.3rc1 −9.7.2-P2
Nam
e S
erve
rs (
thou
sand
s)
9(<0.1%)
244(0.1%)
995(0.4%)
193(0.1%)
2,763(1.0%)
293(0.1%)
1,747(0.7%)
3,438(1.3%)
256,545(96.4%)
Figure 2: Breakdown of BIND versions – Dataset I.
0
50
100
150
BIND9.2.[3-8]
BIND9.3.*
BIND9.4.*
BIND9.5.*
BIND9.6.*
BIND9.7.*
UnknownBIND 9Version
Nam
e S
erve
rs (
thou
sand
s)
21,221(8.0%)
76,146(28.6%)
21,278(8.0%) 10,022
(3.8%)
11,535(4.3%)
5,959(2.2%)
120,066(45.1%)
Figure 3: Breakdown of BIND 9 versions – Dataset I.
5
4 NAME SERVER SOFTWARE VERSIONS
Figures 4, 5, and 6 summarize the distribution of name server software versions for Dataset II.
0
20
40
60
80
100
120
BIN
D
DJ
Ber
nste
inT
inyD
NS
JHS
OF
Tsi
mpl
e D
NS
plu
s
bboy
MyD
NS
Pow
erD
NS
shee
rdns
Nom
inum
AN
S
Mic
roso
ft D
NS
(Win
dow
s 20
03)
Ultr
aDN
S
Mic
roso
ft D
NS
(Win
dow
s 20
00)
NLn
etLa
bs N
SD
Sou
rcef
orge
JDN
SS
Cis
co C
NR
TZ
O T
zolk
in D
NS
Mic
roso
ft D
NS
(Win
dow
s N
T4)
XB
ILL
jnam
ed(d
nsja
va)
Dan
Kam
insk
yno
mde
DN
S tu
nnel
Ver
iSig
n A
TLA
S
(oth
er)
(tim
e ou
t)
(no
mat
ch)
Nam
e S
erve
rs (
thou
sand
s)
103,299(53.9%)
3,716(1.9%)
1,389(0.7%)
1,270(0.7%)
772(0.4%)
640(0.3%)
143(0.1%)
72(< 0.1%)
65(< 0.1%)
59(< 0.1%)
48(< 0.1%)
19(< 0.1%)
14(< 0.1%)
14(< 0.1%)
13(< 0.1%)
12(< 0.1%)
11(< 0.1%)
11(< 0.1%)
71(< 0.1%)
14,296(7.5%)
65,672(34.3%)
Figure 4: Distribution of name server software versions – Dataset II.
6
0
20
40
60
80
100
120
BIND4.9.3 −4.9.11
BIND8.1-REL −
8.2.1
BIND8.2.2-P3 −8.3.0-T2A
BIND8.3.0-RC1 −
8.4.7-P1
BIND9.0.0b5 −
9.0.1
BIND9.1.0 −
9.2.0rc3
BIND9.2.0a1 −9.2.2-P3
BIND9.2.3rc1 −9.7.2-P2
Nam
e S
erve
rs (
thou
sand
s)
43(<0.1%)
131(0.1%)
83(0.1%)
1,779(1.7%)
4(<0.1%)
55(0.1%)
2,176(2.1%)
99,027(95.9%)
Figure 5: Breakdown of BIND versions – Dataset II.
0
20
40
60
BIND9.2.[3-8]
BIND9.3.*
BIND9.4.*
BIND9.5.*
BIND9.6.*
BIND9.7.*
UnknownBIND 9Version
Nam
e S
erve
rs (
thou
sand
s)
13,261(13.4%)
46,700(47.2%)
7,199(7.3%) 3,403
(3.4%)2,711(2.7%)
1,428(1.4%)
24,325(24.6%)
Figure 6: Breakdown of BIND 9 versions – Dataset II.
7
5 OPEN RESOLVERS
5 Open Resolvers
Interest in open resolvers derives from their potential use in DNS amplification attacks.[3] To testfor open resolvers, we utilized a domain name we control, and then sent a specially crafted queryfor it to each responding name server in both data sets. Each query had an encrypted label withencoded values for the IP address of the original target host as well as the time of transmission.We then recorded incoming queries for the name and reconciled them with the original queries.
5.1 Open Resolvers in Dataset I
Of responding hosts in Dataset I, 596,025 (79.6%) returned valid replies in response to recursivequeries. This is down slightly from last year’s figure of 81.4%. Extrapolating to the entire addressspace, we estimate that there are as many as 11,920,500 open resolvers on the Internet.
After reconciling the incoming query sources with the original targets, we determined that most(96.6%) of these acted only as proxies, sending queries to other name servers for resolution.
In examining the distinct query sources, we found:
• 19,035 direct open “emitters”, i.e., open resolvers from which we received queries fromdirectly.
• 33,515 indirect open “emitters”, i.e., hosts from which we received queries when we sentqueries to a different host.
There was an overlap of 953 hosts between these two sets. In other words, we received queriesfrom these hosts both when we queried them directly and also when querying other hosts. Aftertaking this into account, we recorded a total of 51,597 distinct open emitters.
In estimating the number of open emitters on the Internet, there is little point in making a linearextrapolation from the above figure. Most of the query sources were not in the 5% sample, and itis likely that many of the same hosts would have responded given an entirely different sample set.However, we can establish a lower bound from the number of direct open emitters. Therefore weestimate that there are at least 380,700 open emitters on the Internet, comprising 0.02% ofthe routed address space.
The total number of open resolvers on the Internet appears to be decreasing with time, but itis still quite high. We urge developers and manufacturers to read and implement RFC 5625,DNS Proxy Implementation Guidelines.[4] Administrators should read and implement RFC 5358,Preventing Use of Recursive Nameservers in Reflector Attacks.[5]
5.2 Relationship Between Open Proxies and Resolvers in Dataset I
Figure 7 characterizes the “many-to-some” relationship between open proxies and resolvers. Morethan 50% of the queries sent to the 592,145 distinct open proxies were resolved by just 232 resolvers.In total there were 33,515 resolvers acting on behalf of proxies. Note that it is unlikely that all ofthese are proxies in the strict sense of the term; some are almost certainly hosts with multiple IPaddresses. However the incidence of this is probably relatively low, as only 13,064 (2.2%) of theobserved proxy/resolver pairs were in the same /24, and only 44,660 (7.5%) were in the same /16.
8
Ope
n P
roxi
es
Resolvers(in decending order of number of associated proxies)
0
500
1000
1500
2000
2500
3000
3500
4000
4500
0 100 200 300 400 500
Figure 7: The many-to-some relationship between open proxies and resolvers.
Ope
n P
roxi
es
Resolvers Networks (/24s)(in decending order of number of associated proxies)
0
5000
10000
15000
20000
25000
30000
0 20 40 60 80 100
Figure 8: The many-to-some relationship between open proxies and resolver networks.
The concentration of proxies to resolvers becomes even clearer when we look at the many-to-somerelationship between proxies and resolver networks (Figure 8). More than 50% of the queries sentto proxies arrived back to us via resolvers on just 70 /24s.
9
6 SOURCE PORT RANDOMIZATION 5.3 Open Resolvers in Dataset II
5.3 Open Resolvers in Dataset II
Of the zones in Dataset II, 114,753 (10.2%) had at least one authoritative name server that isalso an open resolver. This is up from last year’s figure of 7.1%. Additionally, 93,304 (20.5%) ofname servers from Dataset II had recursion enabled. This is down from last year’s figure of 24.2%.One possible interpretation of these opposing changes is that there are fewer poorly configuredauthoritative name servers but comparatively more zones served by them.
In all, we found:
• 15,446 direct open “emitters”, i.e., open resolvers from which we received queries fromdirectly.
• 8,853 indirect open “emitters”, i.e., hosts from which we received queries when we sentqueries to a different host.
There was an overlap of 3,328 hosts between these two sets. In other words, we received queriesfrom these hosts both when we queried them directly and when querying other hosts. After takingthis into account, we recorded a total of 20,971 distinct open emitters, 10.9% of the name serversin Dataset II.
Unlike in Dataset I, many of the indirect emitters appear to be hosts with multiple IP addresses:5,304 (59.9%) of them are on the same /24 as the proxy, and 4,014 (45.3%) are within the same/28. This would account for the substantial overlap between the direct and indirect emitters.
6 Source Port Randomization
Caching resolvers that send queries from predictable source ports are vulnerable to cache poisoningattacks. We examined the source port characteristics of the open resolvers we found in both datasets.
We wrote a daemon to listen for incoming DNS queries with a particular QNAME and return areply with a CNAME reference to a name served by a second instance of the daemon. The secondinstance then returned a CNAME reference to a name served by the first. The process repeateduntil five queries had been received from the source3, upon which the daemon returned an A RR.4
We then sent a specially crafted query to each open resolver in both data sets. As with the openresolver test, each query had an encrypted label with encoded values for the IP address of theoriginal target host as well as the time of transmission. We then recorded incoming queries andreconciled them with the original queries.
The results have been divided into resolvers with clear patterns of port utilization and resolverswith no obvious pattern. We cannot say with certainty that a given resolver has good randomiza-tion as there is no reliable test for randomness (especially with a sample set of only five queries);however, if a resolver exhibits no obvious pattern, it is a good indication that the implementorhas taken steps to randomize source port utilization.[6]
3The sequence number of the query was encoded into the CNAME reference.4We limited the test to five queries as at least one well-known resolver detects a loop on the sixth lookup and
returns SERVFAIL.
10
6.1 Port Randomization in Dataset I
The source port characteristics of the open resolvers in Dataset I are summarized in Figure 9.Note that this data set consists primarily of open DNS proxies and resolvers. Accordingly, it isunlikely that these are provisioned and maintained with the same hygiene as the majority of keyresolvers used by ISPs and major organizations. As a result, they may have a higher incidence ofpoor source port randomization.
0
100
200
300
400
500
600
700
Same Port Mono-tonically
Increasing
Mono-tonically
Decreasing
Alternating Cycling LimitedRange
NoObviousPattern
Nam
e S
erve
rs (
thou
sand
s)
25,052(4.3%)
438(0.1%)
4(<0.1%)
785(0.1%)
510(0.1%)
982(0.2%)
553,538(95.2%)
Figure 9: Source port randomization – Dataset I.
Of the open resolvers in Dataset I, 95.2% showed no obvious pattern; this is up from 89.8% in the2009 survey. In effect, the number of servers with poor randomization was halved since last year’ssurvey, a significant improvement.
11
6 SOURCE PORT RANDOMIZATION 6.1 Port Randomization in Dataset I
Figure 10 shows the distribution of server software versions that exhibited poor port randomiza-tion. While BIND 9 ranks high on this list, this represents older versions of BIND 9 only; versionsreleased on or after July 8, 2008 (9.5.0-P2 or greater, 9.4.2 or greater, and 9.3.5-P2 or greater)implement port randomization (although this can be overridden).[7]
0
5
10
15
20
BIN
D 9
Mik
rotik
dsl
/cab
le
Mic
roso
ft D
NS
(Win
dow
s 20
00)
Nom
inum
CN
S
BIN
D 8
JHS
OF
Tsi
mpl
e D
NS
plu
s
Mic
roso
ft D
NS
(Win
dow
s 20
03)
Mic
roso
ft D
NS
(Win
dow
s N
T4)
(oth
er)
(tim
e ou
t)
(no
mat
ch)
Nam
e S
erve
rs (
thou
sand
s) 16,035(57.7%)
1,480(5.3%) 351
(1.3%)
294(1.1%)
279(1.0%)
114(0.4%)
110(0.4%)
74(0.3%)
234(0.8%)
991(3.6%)
7,809(28.1%)
Figure 10: Name server software versions with apparently poor port randomization – Dataset I.
12
6.2 Port Randomization in Dataset II
The source port characteristics of the open resolvers in Dataset II are summarized in Figure 11.As with Dataset I, it is unlikely that these servers are provisioned and maintained with the samehygiene as most key resolvers.
0
5
10
15
20
25
Same Port Mono-tonically
Increasing
Mono-tonically
Decreasing
Alternating Cycling LimitedRange
NoObviousPattern
Nam
e S
erve
rs (
thou
sand
s)
6,418(23.6%)
140(0.5%) 0
122(0.4%)
3(<0.1%)
64(0.2%)
20,438(75.2%)
Figure 11: Source port randomization – Dataset II.
75.2% of open resolvers in Dataset II showed no obvious pattern; this is up from 65.9% in the2009 survey, a significant improvement.
13
6 SOURCE PORT RANDOMIZATION 6.2 Port Randomization in Dataset II
Figure 12 shows the distribution of server software versions that exhibited poor source port ran-domization. As noted above, BIND 9’s high rank is likely due to older versions of BIND 9, as recentversions implement port randomization. Recent versions of PowerDNS Recursor also implementport randomization.
0
1
2
3
4
5
6
7
BIN
D 9
JHS
OF
Tsi
mpl
e D
NS
plu
s
BIN
D 8
Pow
erD
NS
Mic
roso
ft D
NS
(Win
dow
s 20
03)
Mic
roso
ft D
NS
(Win
dow
s N
T4)
Mic
roso
ft D
NS
(Win
dow
s 20
00)
Ver
mic
elli
totd
(oth
er)
(tim
e ou
t)
(no
mat
ch)
Nam
e S
erve
rs (
thou
sand
s) 5,569(82.5%)
245(3.6%)
93(1.4%)
24(0.4%)
20(0.3%)
8(0.1%)
3(<0.1%)
3(<0.1%)
6(0.1%)
213(3.2%)
563(8.3%)
Figure 12: Name server software versions with apparently poor port randomization – Dataset II.
14
7 Results For Dataset II – Authoritative Name Servers
The following tests are specific to Dataset II as they require knowledge of at least one zone forwhich a name server is authoritative.5
7.1 Zone Transfers (AXFR)
For each zone in Dataset II we tested to see whether one or more name servers permitted zonetransfers. Table 2 shows the results. 11.3% of zones had a name server that permitted zonetransfers, down from 15.8% last year.
Count Percent
AXFR permitted 114,050 11.3%AXFR NOT permitted 897,618 88.7%
Table 2: Zones in Dataset II with at least one name server that permitted AXFR.
We also tested each name server in Dataset II to see whether each one individually permitted zonetransfers. Table 3 shows the results. 26.1% of name servers permitted zone transfers, down from32.3% last year.
Count Percent
AXFR permitted 50,004 26.1%AXFR NOT permitted 141,602 73.9%
Table 3: Name servers for zones in Dataset II that permitted AXFR.
7.2 TCP Support
For each zone in Dataset II we tested to see whether one or more name servers permitted TCP-based DNS transactions. Table 4 shows the results. 83.6% of zones had a name server thataccepted TCP, up slightly from 81.6% last year.
Count Percent
TCP permitted 542,518 83.6%TCP NOT permitted 106,359 16.4%
Table 4: Zones in Dataset II with at least one name server that permitted TCP-based DNStransactions.
We also tested each name server in Dataset II to see whether each one individually permittedTCP-based DNS transactions. Table 5 shows the results. 81.4% of name servers permitted TCP,up from 75.9% last year.
5There is no straightforward method to discover what zones are served by an arbitrary name server.
15
8 DNSSEC
Count Percent
TCP permitted 155,873 81.4%TCP NOT permitted 35,733 18.6%
Table 5: Name servers for zones in Dataset II that permitted TCP-based DNS transactions.
8 DNSSEC
2010 has been a significant year for DNSSEC. On July 15th, the root zone was signed, removingone of the most significant barriers to broad DNSSEC deployment. However other obstaclesremain:
• The .com and .net zones are not yet signed.6
• Few registrars support DNSSEC.
• Few resolvers have DNSSEC validation enabled.
• The tools for managing signed zones are basic and typically entail a steep learning curve.
Consequently DNSSEC deployment is still extremely limited.
In Dataset II we found 243 DNSSEC-signed zones.7 Based on this figure, we estimate that 24,300(0.022%) zones are signed in the .com, .org, and .net zones. Put differently, that is onein every 4,619 zones. While this is still a very small proportion, it represents a more than fourfoldincrease over last year’s figure of 0.005%.
TLDProportion ofSigned Zones
.com 0.020%
.net 0.023%
.org 0.040%
Table 6: DNSSEC-signed zones, by TLD.
Table 6 shows the proportion of signed zones by TLD. .org has double the proportion of signedzones that .com does. The .org zone was signed last year, which may account for some of itscomparatively greater popularity.
6VeriSign has announced that the .net zone will be signed in December and the .com zone will be signed inMarch, 2011.
7Four additional zones were found to contain DNSKEY RRs but were unsigned.
16
8.1 KSKs
Table 7 shows the distribution of key signing keys (KSKs) found for each signed zone. Note thatno zones have pre-published KSKs.
Count Percent
No KSK (ZSKs only) 1 0.4%One KSK 242 99.6%
Table 7: KSKs per zone.
8.2 ZSKs
Table 8 shows the distribution of the number of zone signing keys (ZSKs) found for each zone.Last year more than half of signed zones had only one ZSK; this year the opposite is true.
Count Percent
One ZSK 76 31.3%Two ZSKs 167 68.7%
Table 8: ZSKs per zone.
17
8 DNSSEC 8.3 Signature Validity Periods
8.3 Signature Validity Periods
Figure 13 shows the distribution of the signature validity periods found for the signed zones.Fractional values are typically indicative of zones employing online re-signing.
0
50
100
150
200
6.58 7.13 23.20 28 30 30.04 31 90.04 356
Zon
es
Signature Validity Period (days)
1(0.4%)
7(2.9%)
1(0.4%)
1(0.4%)
65(26.7%)
1(0.4%)
163(67.1%)
3(1.2%)
1(0.4%)
Figure 13: Signature validity periods.
18
8.4 KSK Properties
Figure 14 shows the distribution of KSK algorithms, key sizes, and exponent sizes. It is interestingto note that while nearly half of the signed TLDs (as well as the root zone) use RSA-SHA-256 or RSA-SHA-512, not a single zone in the sample used them. RSASHA1 offers more thanadequate security for the foreseeable future, but zone managers deploying DNSSEC for the firsttime may wish to use RSA-SHA-256 or RSA-SHA-512 to avoid the inconvenience of a possiblefuture algorithm rollover.
0
100
200
300
DSA RSASHA1 RSASHA1-NSEC3-SHA1
Zon
es
KSK Algorithm
5(2.0%)
240(96.8%)
3(1.2%)
0
100
200
300
1024 1280 2048 2432 4096
Zon
es
KSK Key Size (bits)
53(21.9%) 3
(1.2%)
179(74.0%)
3(1.2%)
4(1.7%)
0
100
200
300
3 octets 4 octets 5 octets
Zon
es
KSK Exponent Size
238(98.3%)
3(1.2%)
1(0.4%)
Figure 14: KSK properties.
19
8 DNSSEC 8.4 KSK Properties
All keys with three-octet exponent lengths had an exponent value of 65,537, or 10001hex (Fermatnumber F4). The keys with five-octet exponent lengths had an exponent value of 4,294,967,297,or 100000001hex (Fermat number F5). The keys with four-octet exponent lengths appeared tohave exponents of random values that were, curiously, non-prime (with one exception).
20
8.5 ZSK Properties
Figure 15 shows the distribution of ZSK algorithms, key sizes, and exponent sizes.
0
100
200
300
RSAMD5 DSA RSASHA1 RSASHA1-NSEC3-SHA1
Zon
es
ZSK Algorithm
1(0.4%)
3(1.2%)
236(97.1%)
3(1.2%)
0
100
200
300
512 768 1024 1280 2432 4096
Zon
es
ZSK Key Size (bits)
1(0.4%)
1(0.4%)
231(95.1%)
3(1.2%)
3(1.2%)
4(1.6%)
0
100
200
300
3 octets 4 octets 5 octets
Zon
es
ZSK Exponent Size
239(98.4%)
3(1.2%)
1(0.4%)
Figure 15: ZSK properties.
21
8 DNSSEC 8.6 NSEC3
8.6 NSEC3
0
100
200
300
NSEC NSEC3
Zon
es
241(99.2%)
2(0.8%)
Figure 16: Zones using NSEC vs NSEC3.
Figure 16 shows the number of zones using NSEC3. Note that this is not the same as the numberof zones with RSA-SHA1-NSEC3 KSKs, as one of the three zones with an RSA-SHA1-NSEC3KSK is signed using NSEC RRs. Last year five out of 167 signed zones used NSEC3. While thesample size of signed zones is too small to draw any conclusions, it is possible that the use ofNSEC3 in non-registry-class zones is dwindling.
8.7 DNSSEC Validation
0
100
200
300
Validated Expired Failed
Zon
es
187(77.0%)
54(22.2%)
2(0.8%)
Figure 17: Validation statistics.
Figure 17 shows the validation status for the DNSSEC signed zones. Expired zones are zonesthat failed validation but were found to validate if the validator ignored the requirement for thecurrent time to be within the validity period specified in the RRSIG RRs.
Figure 18 shows the number of zones that validated against 1) the KSK within the zone itself,2) the root zone trust anchor, and 3) ISC’s DLV registry trust anchor. Of the TLDs included inthis survey, only .org is signed, so only zones under the .org zone can be validated against the
22
0
100
200
300
Zone Key Root Key ISC DLV
Zon
es
187(93.5%)
9(4.5%)
4(2.0%)
Figure 18: Trust anchors used.
root zone trust anchor. Of the 34 signed zones in the .org zone, only nine had DS RRs in theparent zone; all of these zones validated against the root zone trust anchor. Four zones had DLVRRs in ISC’s DLV Registry; all of these zones validated against the ISC DLV trust anchor. Ofthe two .org zones in the DLV registry, only one had a DS RR in the parent zone. No zone witheither a DS RR in the parent or a DLV RR in the DLV registry failed to validate.
Exp
ired
Sig
ned
Zon
es
Months Since Expiration
0%
20%
40%
60%
80%
100%
0 3 6 9 12 15 18 21
Figure 19: “Staleness” of expired zones (cumulative distribution).
Figure 19 shows the cumulative distribution of elapsed times for each expired zone since thatzone expired. Some of these may be abandoned DNSSEC experiments that were never revertedto unsigned. Others may be attributable to zone managers who are unaware of the requirementto periodically re-sign the zone.
23
9 EDNS
9 EDNS
We tested name servers in both data sets for EDNS support. EDNS is a prerequisite for DNSSEC,as replies containing DNSSEC metadata can easily exceed the legacy DNS message size of 512octets. In order to properly support DNSSEC, a name server must not only have EDNS0 enabled,but it must have a payload size of at least 1,220 octets.
0
100
200
300
400
1280 1460 4000 4096 OtherSize
Unsup-ported
Noreply
Nam
e S
erve
rs(t
hous
ands
)
EDNS0 Payload Size (octets)
28,390(3.7%)
33,998(4.4%)
119,534(15.4%)
322,145(41.4%)
2,819(0.4%)
205,664(26.4%)
65,130(8.4%)
Figure 20: EDNS support – Dataset I.
0
20
40
60
80
100
120
1280 4096 Other Size Unsupported No reply
Nam
e S
erve
rs(t
hous
ands
)
EDNS0 Payload Size (octets)
12,783(6.7%)
105,148(54.9%)
1,028(0.5%)
17,715(9.2%)
54,932(28.7%)
Figure 21: EDNS support – Dataset II.
Figures 20 and 21 show the EDNS payload sizes for the name servers in Dataset I and Dataset IIrespectively. By far the most popular payload size is 4096 octets.
24
10 IPv6
We recorded the number of zones with at least one name server with an IPv6 address. VeriSignbegan accepting AAAA glue records for publication in the .com and .net zones in 2002, and PIRbegan accepting them for the .org zone in 2008. However, domain name registrars have beenslow to extend their systems to accommodate these records. Therefore this statistic should notbe interpreted as a meaningful indicator of the deployment of IPv6 in the global DNS.
TLD Count Percent
.com 10,762 1.2%
.net 2,053 1.5%
.org 1,532 1.8%Total 14,347 1.3%
Table 9: Zones with name servers with AAAA RRs.
Table 9 shows the number zones with name servers that have AAAA RRs. The total of 1.3% is asignificant increase over last year’s figure of 0.7%.
11 SPF and Sender ID
Sender Policy Framework (SPF) and Sender ID are anti-forgery techniques by which organizationscan list valid sources of email (e.g., IP addresses and host names) sent from their domain. Theyare described in RFCs 4408 and 4406.[8][9] To enable SPF authorization, an organization publishesan SPF record in their zone, either as an SPF (Type 99) resource record or as a TXT record. Mailtransfer agents may then look up SPF information when receiving email messages. Sender ID issimilar but, unlike SPF, has no assigned resource record type.
Count Percent
Zones with SPF records (total) 178,785 15.9%— TXT RRs 178,732 15.9%
— SPF RRs 4,557 0.4%
Zones with Sender ID records 771 0.01%
Table 10: Zones with SPF/Sender ID records.
Table 10 shows the number of zones in Dataset II that were found to contain SPF or Sender IDrecords.
25
13 DNS WILDCARDS
12 DKIM
DKIM is an anti-forgery technique by which organizations can sign mail to be validated againstpublic keys published in their zone. It is described in RFC 4871.[10] To enable DKIM validation,an organization publishes one or more DKIM records as TXT records under the sub-domaindomainkey in the desired zone, e.g., key1. domainkey.example.com. Unlike SPF and SenderID, DKIM records cannot be looked up directly without knowing – or attempting to guess – thekey names; however, the presence of the subdomain domainkey in a zone suggests that DKIM isconfigured.
Count Percent
Zones with DKIM subdomains 27,820 2.5%
Table 11: Zones with DKIM subdomains.
Table 11 shows the number of zones in Dataset II that appeared to contain DKIM subdomains.
13 DNS Wildcards
Many administrators put DNS wildcards in their zones. Typical uses include receiving email formultiple subdomains and as a catch-all for misdirected connections. Wildcards are frequentlyfound in the zones of “parked” domains to maximize the clickthrough rate to advertisers.
Count Percent
Zones with DNS wildcard records 470,197 41.9%
Table 12: Zones with DNS wildcard records.
Table 12 shows the number of zones in Dataset II that appeared to contain DNS wildcards for atleast one RR type.
26
14 SOA Values
We checked to see how many zones had SOA values within the ranges advised by RFC 1912 andother recommendations.[11]
14.1 SOA Refresh
RFC 1912 suggests that the SOA Refresh value should be at least 1200 (20 minutes) and no largerthan 43200 (12 hours); however RIPE-203 recommends a value of 86400 (24 hours).[12] Figure 22shows the distribution of refresh values. 97.6% of zones have Refresh values in the recommendedrange if both recommendations are taken together.
Zon
es
SOA Refresh Value (seconds)
0%
20%
40%
60%
80%
100%
0
108
00
216
00
324
00
432
00
540
00
648
00
756
00
864
00
972
00
108
000
118
800
129
600
Recommended values
Figure 22: SOA Refresh values (cumulative distribution).
14.2 SOA Retry
RFC 1912 suggests that the SOA Retry value should typically be less than the Refresh value.Table 13 shows the distribution of Retry values relative to Refresh values.
RFC 1912 suggests that the SOA Expire value should be at least 1209600 (two weeks) and nolarger than 2419200 (four weeks). RIPE-203 recommends a value of 3600000 (1000 hours, or 41days). Figure 23 shows the distribution of expire values.
Zon
es
SOA Expire Value (seconds)
0%
20%
40%
60%
80%
100%
0
6048
00
1209
600
1814
400
2419
200
3024
000
3628
800
4233
600
4838
400
5443
200
6048
000
6652
800
7257
600
Recommendedvalues
Figure 23: SOA Expire values (cumulative distribution).
Only 18.2% of zones in Dataset II have Expire values in the recommended range. In fact, mostzones have an Expire value of 604800 (one week). This potentially puts them at greater riskof becoming unavailable during an extended outage. It should be noted that the Internet haschanged considerably since these recommendations were made. It is rarer to find zones whosename servers are managed by separate entities. Consequently this value is less important than itonce was. Nevertheless, the recommendations are still valid.
14.4 SOA Minimum
RFC 2308 advises that the SOA Minimum value (the TTL to be used for negative responses)works well when it is between 3600 (one hour) and 10800 (three hours).[13] This recommendationsupersedes those in RFC 1912 and RIPE-203, which were written when the Minimum value haddifferent (now deprecated) semantics. Figure 24 shows the distribution of Minimum values.
Surprisingly, only 22% of zones have Minimum values in the recommended range. Nearly 50%have a value of 86400 (one day). This is likely because many administrators are unaware of thechange in semantics introduced by RFC 2308. However, common name server implementationsusually enforce a negative caching limit of three hours or less, which mitigates the deleteriouseffects of large Minimum values.
28
Zon
es
SOA Minimum Value (seconds)
0%
20%
40%
60%
80%
100%
0
108
00
216
00
324
00
432
00
540
00
648
00
756
00
864
00
972
00
Recommended values
Figure 24: SOA Minimum values (cumulative distribution).
14.5 SOA Serial Number
Non-matching serial numbers on different authoritative servers for a zone may indicate a config-uration problem.
Count Percent
Serial numbers match 959,069 98.5%Serial numbers DO NOT match 14,240 1.5%
Table 14: Zones with non-matching SOA serial numbers.
Table 14 shows the distribution of zones with matching and non-matching serial numbers. Notethat these results include only zones that responded with at least one valid SOA record.
15 Matching of Authoritative NS Records
We tested to see whether delegation NS records (in the parent zone) match the authoritative NSrecords (in the child zone). We distinguish between “match”, “not match”, and the case wherethe supposedly authoritative name servers (learned from the parent zone) did not return any NSrecords for the zone. Table 15 shows the results. The number of mismatches was down slightlyfrom last year’s figure of 7.9%.
29
18 TOPOLOGICAL DISPERSION OF NAME SERVERS
Count Percent
Zones whose NS record match 567,732 50.7%Zones whose NS record are mismatched 81,518 7.3%Zones with no authoritative name server 470,969 42.0%
Table 15: Agreement between delegation and authoritative data.
16 Name Server Lameness
We tested for lameness by sending an SOA query for the zone to each authoritative name server.If the response’s RCODE was anything other than zero (NOERROR), we surmised that the nameserver was lame. Table 16 shows the number of zones with at least one lame name server.
Count Percent
Not Lame 939,435 91.6%Lame 86,193 8.4%
Table 16: Name server lameness.
Note that an unresolvable name server was not considered to be a lame server. In other words, ifa zone had three name servers and we were unable to obtain an IP address for one of them, thezone was not considered to have a lame server provided that the other two name servers were notlame.
17 Matching of TTLs Across NS Records
RFC 1033 notes that all RRs with the same name, class, and type should have the same TTLvalue.[14] When the authoritative name servers for a zone have different TTLs, it is possiblefor name resolution to fail, particularly if the NS RRs with the longest TTLs are for lame orunreachable name servers. Table 17 shows the number of zones whose NS RRs all have the sameTTLs vs the number that didn’t.
Count Percent
Zones w/ same TTLs for all NS RRs 647,782 98.83%Zones w/ NS RRs with differing TTLs 1,129 0.17%
Table 17: TTL mismatches.
18 Topological Dispersion of Name Servers
RFC 2182 advises that “secondary servers must be placed at both topologically and geographicallydispersed locations on the Internet, to minimize the likelihood of a single failure disabling all ofthem.”[15]
30
While we do not test for geographic diversity, we can evaluate the topological aspects of a zone’sname servers. Topological proximity often belies geographic proximity: when two name serversare in the same /24 subnet, they are usually also geographically close to each other. Occasionally,anycast and other routing techniques make geographically distant hosts appear as if they are onthe same subnet, but this is atypical.
0
10
20
30
40
50
60
/32/31
/30/29
/28/27
/27/25
/24/23
/22/21
/20/19
/18/17
/160%
2%
4%
6%
8%
Zon
es (
thou
sand
s)
CIDR Mask
0%
2%
4%
6%
8%
Figure 25: Topological dispersion of name servers – Dataset II.
Figure 25 shows the number of zones having all their authoritative name servers within a givenCIDR-sized subnet.
Zon
es
CIDR Mask
0%
20%
40%
60%
80%
100%
/32/31
/30/29
/28/27
/27/25
/24/23
/22/21
/20/19
/18/17
/16/15
/14/13
/12/11
/10/9
/8/7
/6/5
/4/3
/2/1
/0
Figure 26: Topological dispersion of name servers – Dataset II (cumulative distribution).
Figure 26 shows the cumulative distribution of zones having all their authoritative name serverswithin a given CIDR-sized subnet. 19.5% of zones have name servers that are wholly containedwithin the same /24 subnet, which is particularly undesirable.
31
19 AUTONOMOUS SYSTEM DIVERSITY OF NAME SERVERS
19 Autonomous System Diversity of Name Servers
BGP routing interruptions, while infrequent, are one of the more common causes of transientunreachability between two hosts. To ensure maximum reachability, a zone’s name servers shouldbe split across at least two Autonomous Systems (ASes).
To determine the AS of each name server in Dataset I, we used a copy of the CAIDA RouteviewsPrefix to AS Mappings Dataset (pfx2as).[16] We then noted the number of distinct ASes used bythe authoritative name servers for each zone.
0
200
400
600
800
1 2 3 4 5 6 7 8 9 unknown
Zon
es (
thou
sand
s)
Number of Autonomous Systems
738,027(73.0%)
233,592(23.1%)
33,984(3.4%)
4,638(0.5%)
1,180(0.1%)
77(<0.1%)
129(<0.1%)
5(<0.1%)
5(<0.1%)
31(<0.1%)
Figure 27: Number of zones having all of their authoritative name servers within a given numberof Autonomous Systems.
Figure 27 shows the number of zones having all of their authoritative name servers within thegiven number of Autonomous Systems. Over 72% of zones have all of their name serversin one AS only. If a routing issue arises between the AS containing the zone’s name serversand another AS, hosts in the other AS will be unable to resolve the domain. Most Internet usersexperience this type of interruption on occasion, usually without knowing the cause.
Note that in a small number of cases, all of the name servers for a zone are in a single AS thatachieves sufficient resilience via IPv4 anycast routing.[17]
32
20 0x20 Behavior
One proposal for improving the resilience of DNS resolvers against forgery involves utilizing thehigh bit of the alphabetical characters in the QNAME as additional entropy in DNS transactions.[18]This proposal is generally referred to as 0x20.8 This technique requires that name servers preservethe case of characters in the QNAME in the Question section of a DNS reply.
20.1 0x20 Behavior in Dataset I
We sent a query for A.rOOT-SerVeRs.NEt to each responding host in Dataset I to see whetherthe case was preserved in the reply. Figure 28 shows the results. “Other” means the name serverreturned a reply that contained a DNS header only, e.g., REFUSED or SERVFAIL. The 0x20behavior could not be determined for these hosts as no Question section was present in the reply.
The large number of timeouts is likely due to the test for 0x20 behavior being run a week afterthe initial probes to establish Dataset I. As many name servers in Dataset I have ephemeralIP addresses, these timeouts probably reflect IP address changes during the interim rather thanfailure to reply to queries with mixed-case QNAMEs.
0
100
200
300
400
500
600
0x20-Ready 0x20-Unready Other Timeout
Nam
e S
erve
rs (
thou
sand
s) 461,079(59.3%)
23,213(3.0%)
2,226(0.3%)
291,162(37.4%)
Figure 28: 0x20-ready name servers – Dataset I.
Figure 29 shows the distribution of server versions that did not support 0x20 in Dataset I. Note thatthe implementation labeled “unknown” was reported by fpdns to be VeriSign ATLAS; howevernearly all of these hosts have version.bind values that suggest that they are older versions ofBIND 9. These hosts were concentrated in a relatively small number of networks, and may bepatched versions of BIND, or some variant of BIND. Alternatively, they may be proxies that aredowncasing QNAMEs before (or even after) they reach a BIND server.
80x20 refers to the position of the bit that differentiates uppercase from lowercase characters in ASCII.
33
20 0X20 BEHAVIOR 20.1 0x20 Behavior in Dataset I
0
2
4
6
8
10
12
14
16
18
Mik
rotik
dsl/c
able
unkn
own
(fpd
ns s
ays
Ver
iSig
nA
TLA
S)
robt
ex V
ikin
gD
NS
mod
ule
shee
rdns
JHS
OF
Tsi
mpl
eD
NS
plu
s
(oth
er)
(tim
e ou
t)
(no
mat
ch)
Nam
e S
erve
rs (
thou
sand
s) 14,720(63.4%)
3,324(14.3%) 2,445
(10.5%)267
(1.2%)36
(0.2%)
189(0.8%)
91(0.4%)
2,141(9.2%)
Figure 29: Distribution of name server software versions that are not 0x20-ready – Dataset I.
34
20.2 0x20 Behavior in Dataset II
For each name server in Dataset II, we sent a query for the SOA RR of a zone for which it wasauthoritative. For a QNAME containing n letters, we set ⌊n/2⌋ random letters to uppercase andleft the remaining letters as lowercase .
Figure 30 shows the results. Again, “Other” means the name server returned a reply that containeda DNS header only.
0
20
40
60
80
100
120
140
160
0x20-Ready 0x20-Unready Other Timeout
Nam
e S
erve
rs (
thou
sand
s) 124,657(91.0%)
263(0.2%)
5,074(5.1%)
7,035(3.7%)
Figure 30: 0x20-ready name servers – Dataset II.
Figure 31 shows the distribution of server versions that did not support 0x20 in Dataset II. It isremarkable that only two identifiable implementations were found not to support 0x20 in DatasetII.
0
50
100
150
JHSOFTsimple DNS plus
Mikrotik-dsl cable (timeout) (no match)
Nam
e S
erve
rs
118(45.2%)
5(1.9%)
44(16.9%)
94(36.0%)
Figure 31: Distribution of name server software versions that are not 0x20-ready – Dataset II.
35
21 GEOGRAPHIC LOCATION
21 Geographic Location
We used a recent copy of the MaxMind GeoIP Country geolocation database to determine thelocation (by country) of the name servers in both datasets.[19] We then compared these with theaddress space in use by each country (via the Routeviews and GeoIP datasets) to estimate thename server density for each country.
21.1 Name Server Location
Figure 32 shows the distribution of the top 60 countries with responding name servers fromDataset I.
0
20
40
60
80
100
120
140
160
Uni
ted
Sta
tes
Chi
naS
pain
Sou
th K
orea
Fra
nce
Bra
zil
Tur
key
Japa
nG
erm
any
Italy
Uni
ted
Kin
gdom
Cze
ch R
epub
licR
ussi
an F
eder
atio
nN
ethe
rland
sD
enm
ark
Tai
wan
Arg
entin
aC
anad
aP
olan
dT
haila
ndP
eru
Aus
tral
iaS
audi
Ara
bia
Por
tuga
lC
hile
Sw
itzer
land
Sw
eden
Indi
aB
ulga
riaU
krai
neV
ietn
amR
oman
iaM
alay
sia
Nor
way
Hun
gary
Hon
g K
ong
Indo
nesi
aA
ustr
iaU
nite
d A
rab
Em
irate
sS
outh
Afr
ica
Phi
lippi
nes
Col
ombi
aC
roat
iaF
inla
ndB
elgi
umE
gypt
Gre
ece
Pak
ista
nN
ew Z
eala
ndS
lova
kia
Iran
Isra
elIr
elan
dS
inga
pore
Geo
rgia
Mex
ico
Ser
bia
Latv
iaD
omin
ican
Rep
ublic
Bol
ivia
Oth
er
0%
5%
10%
15%
20%
Nam
e S
erve
rs (
thou
sand
s)
Figure 32: Geographic location of name servers – Dataset I.
36
Figure 33 shows the distribution of the top 60 countries with responding name servers fromDataset II. Note that this plot has a broken y-axis, and that the number of name servers in theUnited States is actually more than ten times the number in the United Kingdom or Germany,the next closest countries.
1
2
3
4
5
6
7
74
75
76
Uni
ted
Sta
tes
Uni
ted
Kin
gdom
Ger
man
yC
anad
aN
ethe
rland
sF
ranc
eT
urke
yS
pain
Japa
nIta
lyA
ustr
alia
Sou
th K
orea
Chi
naR
ussi
an F
eder
atio
nT
haila
ndS
witz
erla
ndH
ong
Kon
gB
razi
lS
wed
enP
olan
dM
alay
sia
Aus
tria
Ukr
aine
Bel
gium
Arg
entin
aB
ulga
riaC
zech
Rep
ublic
Hun
gary
Sin
gapo
reP
ortu
gal
Fin
land
Indi
aN
orw
ayIn
done
sia
Den
mar
kT
aiw
anR
oman
iaIs
rael
Irel
and
New
Zea
land
Slo
veni
aS
outh
Afr
ica
Vie
tnam Iran
Mex
ico
Chi
leG
reec
eS
lova
kia
Col
ombi
aLa
tvia
Pan
ama
Est
onia
Ven
ezue
laS
erbi
aC
roat
iaLi
thua
nia
Mor
occo
Phi
lippi
nes
Cyp
rus
Luxe
mbo
urg
Oth
er
1%
2%
3%
4%
5%
54%
55%
Nam
e S
erve
rs (
thou
sand
s)
United States: 75,815 (55.5%)
1%
2%
3%
4%
5%
54%
55%
Figure 33: Geographic location of name servers – Dataset II.
37
21 GEOGRAPHIC LOCATION 21.2 Name Server Density
21.2 Name Server Density
Figure 34 shows the estimated density for the top 60 countries (by name server count in Dataset I)with respect to their allocated and routed address space. There were countries with greaterdensities than those shown here; however, in most cases this was due to a country with very fewservers having proportionately even less allocated address space. It therefore made sense to focuson the countries with the most name servers.
0%
1%
2%
3%
4%
5%
6%
7%
Per
uS
pain
Tur
key
Cze
ch R
epub
licS
audi
Ara
bia
Bol
ivia
Bul
garia
Dom
inic
an R
epub
licG
eorg
iaC
roat
iaD
enm
ark
Chi
leA
rgen
tina
Fra
nce
Por
tuga
lT
haila
ndU
nite
d A
rab
Em
irate
sB
razi
lH
unga
ryM
alay
sia
Sou
th K
orea
Ukr
aine
Slo
vaki
aP
akis
tan
Vie
tnam
Latv
iaR
ussi
an F
eder
atio
nP
olan
dP
hilip
pine
sN
ethe
rland
sIn
done
sia
Chi
naR
oman
iaS
erbi
aIta
lyIr
anS
witz
erla
ndC
olom
bia
Tai
wan
Hon
g K
ong
Indi
aG
reec
eE
gypt
New
Zea
land
Uni
ted
Kin
gdom
Oth
erA
ustr
iaN
orw
ayS
wed
enS
inga
pore
Can
ada
Ger
man
yU
nite
d S
tate
sB
elgi
umA
ustr
alia
Isra
elIr
elan
dJa
pan
Sou
th A
fric
aF
inla
ndM
exic
o
Est
imat
ed N
ame
Ser
ver
Den
sity
Figure 34: Density of name servers by country – Dataset I.
38
Figure 35 shows the estimated density for the top 60 countries (by name server count in DatasetII) with respect to their allocated and routed address space.
0.0%
0.5%
1.0%
1.5%
2.0%
2.5%
3.0%
Tur
key
Tha
iland
Spa
inB
ulga
riaS
love
nia
Can
ada
Net
herla
nds
Cyp
rus
Sin
gapo
reM
alay
sia
Hun
gary
Hon
g K
ong
Uni
ted
Kin
gdom
Uni
ted
Sta
tes
Fra
nce
Por
tuga
lU
krai
neIr
anC
zech
Rep
ublic
Mor
occo
Indo
nesi
aE
ston
iaG
erm
any
Sw
itzer
land
Luxe
mbo
urg
Aus
tria
Latv
iaP
anam
aA
rgen
tina
Bel
gium
Isra
elA
ustr
alia
Italy
New
Zea
land
Irel
and
Slo
vaki
aR
oman
iaP
olan
dC
roat
iaS
erbi
aF
inla
ndS
wed
enR
ussi
an F
eder
atio
nLi
thua
nia
Den
mar
kC
hile
Nor
way
Indi
aB
razi
lG
reec
eV
ietn
amJa
pan
Ven
ezue
laO
ther
Col
ombi
aS
outh
Afr
ica
Sou
th K
orea
Phi
lippi
nes
Tai
wan
Mex
ico
Chi
na
Est
imat
ed N
ame
Ser
ver
Den
sity
Figure 35: Density of name servers by country – Dataset II.
39
REFERENCES REFERENCES
References
[1] University of Oregon Route Views Project. http://www.routeviews.org/
[2] fpdns. http://code.google.com/p/fpdns/
[3] Scalzo, F., Recent DNS Reflector Attacks From the Victim and the Reflector POV, presentedat NANOG 37, May, 2006. http://www.nanog.org/meetings/nanog37/presentations/
frank-scalzo.pdf
[4] Bellis, R., DNS Proxy Implementation Guidelines, RFC 5625, BCP 152, August 2009. http://tools.ietf.org/html/rfc5625
[5] Damas, J. and F. Neves, Preventing Use of Recursive Nameservers in Reflector Attacks ,RFC 5358, BCP 140, October 2008. http://tools.ietf.org/html/rfc5358
[6] Laurie, B., Is Your DNS Really Safe?, July 2008. http://www.links.org/?p=352
[7] Internet Systems Consortium, DNS Cache Poisoning Issue (“Kaminsky bug”) (ISC Advisory),July 2008. http://www.isc.org/software/bind/advisories/cve-2008-1447
[8] Wong, M., and W. Schlitt, Sender Policy Framework (SPF) for Authorizing Use of Domainsin E-Mail, Version 1, RFC 4408, April 2006. http://tools.ietf.org/html/rfc4408
[9] Lyon, J., and M. Wong, Sender ID: Authenticating E-Mail, RFC 4406, April 2006. http://tools.ietf.org/html/rfc4406
[10] Allman, E., et al., DomainKeys Identified Mail (DKIM) Signatures, RFC 4871, May 2007.http://tools.ietf.org/html/rfc4871
[11] Barr, D., Common DNS Operational and Configuration Errors, RFC 1912, February 1996.http://tools.ietf.org/html/rfc1912
[12] Koch, P., Recommendations for DNS SOA Values, ripe-203, June 1999. http://www.ripe.net/docs/dns-soa.html
[13] Andrews, M., Negative Caching of DNS Queries (DNS NCACHE), RFC 2308, March 1998.http://tools.ietf.org/html/rfc2308
[14] Lottor, M., Domain Administrators Operations Guide, RFC 1033, March 1987. http://tools.ietf.org/html/rfc1033
[15] Elz, R., et al., Selection and Operation of Secondary DNS Servers, RFC 2182, July 1997.http://tools.ietf.org/html/rfc2182
[16] CAIDA Routeviews Prefix to AS mappings Dataset. http://www.caida.org/data/routing/routeviews-prefix2as.xml
[17] Abley, J. and K. Lindqvist, Operation of Anycast Services, RFC 4786, BCP 126, Decem-ber 2006. http://tools.ietf.org/html/rfc4786
[18] Vixie, P., and D. Dagon, Use of Bit 0x20 in DNS Labels to Improve Transaction Identity, Workin Progress, March 2008. http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
[19] MaxMind GeoIP Country Database. http://www.maxmind.com/app/country
