Measuring DNS Vulnerabilities and DNSSEC
Challenges from an Irish Perspective
William J. Glynn IE Domain Registry (IEDR)
billy.glynn@iedr.ie
Abstract—This security research measures the extent to which Irish authoritave name servers, for second-level dot IE domains, are vulnerable to well-known DNS vulnerabilities, particularly Kaminsky-style attacks. The research continues with an analysis of the problems posed by the introduction of security extensions to the domain name system in Ireland. It aims to ascertain if problems exist and if they do exist, it attempts to establish to what extent the problems persist in an Irish context. In the consideration of the extent of the potential problems, the research endeavours to quantify and prove that the problems are not the responsibility of any one internet infrastructure provider, but rather that the problems are more distributed.
Index Terms—DNS, DNSSEC, PMTU, ccTLD, cache-poisoning, Ireland
I. INTRODUCTION
T
HE domain name system (DNS) is used at the outset of almost every instance of network communication. While the operators of the DNS fulfil many different functions, the core function of the DNS is to provide a directory service. When one enters an address or URL in a browser such as www.gov.ie, the DNS lets the computer know where the information can be located by referring to the relevant IP address. The DNS internet protocol was originally designed with virtually no security in its specifications. However, the protocol was fit for purpose during the earlier days of the internet in the 1980s and early 1990s. Accordingly, DNS has several distinct classes of vulnerabilities which may be exploited in an insidious manner. The most significant vulnerability results from the fact that name servers query each other, without a method to verify that the results are genuine, or even originate from the proper name server. This allows for a type of attack called cache poisoning. One particular variant, the Kaminsky DNS cache poisoning attack, allows the attacker to take control of specific domains, or to take control of domains up the DNS hierarchy. These DNS vulnerabilities provide a real and present danger to Internet security and have the potential to erode consumer confidence in transacting online or lead to serious financial losses, for instance where the attacker succeeds in harvesting online banking login details from unsuspecting bank customers. The quantitative deductive research undertaken in this paper includes thorough risk analysis of Irish-based DNS name servers and finds that a surprising number of high profile public and private bodies remain exposed to the aforementioned vulnerability. The solution to cache poisoning attacks and other threats to the DNS is DNS SecurityExtensions or DNSSEC. DNSSEC provides data origin authentication and data integrity verification to the DNS through the use of public key cryptographic signatures. Public key cryptography uses asymmetric key algorithms of mathematically related key pairs in the form of a secure private key and a published public key. The combination of the key pair enables the verification of the authenticity of a DNS message through the creation of a digital signature of the DNS data using the secure private key. These keys are used to sign zone data. However, the inclusion of cryptographic signatures in DNS queries and responses leads to an increase in DNS packet sizes. The increase in DNS packets sizes can lead to Path Maximum Transmission Unit (PMTU) issues. The paper presents the opportunities and challenges which the deployment of DNSSEC may bring, specifically Path Maximum Transmission Unit (PMTU) issues. In particular, this analysis observes servers which look up the addresses of Irish internet names ending in dot IE. In doing so, it determines whether or not these servers are already capable and requesting “secured” domain name information. Furthermore, it quantifies the number of these servers. It drills down into the finer detail of the data presented by these servers and ascertains what the servers claim to be their network link capacity, or “the number of octets of the largest UDP payload that can be reassembled and delivered in the sender’s network stack”[11]. International research in this field has asserted that this advertised or claimed network capacity may be at variance with actual capacity. This analysis strives to quantify the variance between the advertised and actual network capacity. It does so, because a lower actual network capacity than that advertised by a server would be critical, in so far as it would cause a response to a domain name lookup to never be delivered to the recipient or querying server. The rest of this paper proceeds as follows. Firstly, an analysis is undertaken which considers the extent to which second-level dot IE authoritative name servers are vulnerable. That anaylsis considers vulnerabilities in terms of whether the name servers are also recursive and open resolvers. When that is found to be the case, the resolvers are probed to ascertain the randomness of the source port. Predictable ports can easily lead to a poisoned DNS cache. The same data set are probed using the fpdns fingerprinting tool to
measure the extent to which the name servers within the data set are running older versions of name server software. Secondly, an analysis was undertaken whereby the source IP addresses, as seen by the authoritative dot IE name servers, are scanned using a reply-size test server. The data returned from such measurements gave an indication of the path maximum tranmission unit which was compared with the EDNS0 buffer size of such queries. These comparisons may be useful to indicate where possible DNSSEC deployment issues may arise, in scenarios where middle-ware or CPE incorrectly drop fragmented datagrams.
II. METHODOLOGY
A. Quantifying the vulnerability of second-level dot IE author-itative name servers to cache poisoning
The extent to which name servers for dot IE domains were vulnerable was considered throughout the summer of 2010. That research is updated in this paper with more recent measurements. To achieve this, the source port randomness was measured for open recursive name servers which are also authoritative for dot IE domains. Following the United States Computer Emergency Readiness Team’s publication of the vulnerability note[4], the DNS-OARC designed a name server that assists in the measurement of source port randomness. Figure 1, below, is an example measurement command.
dig @4.2.2.3 +short porttest.dns-oarc.net TXT
Figure 1. Source Port Randomness Measurement Command
The measurements indicate the source port randomness based on the standard deviation of observed source ports. The standard deviation term was allocated by DNS-OARC to indicate the mean difference between the source ports observed over an amount of queries. For all measurements, the amount of queries was alway greater than 25.
The ratings allocated by DNS-OARC are presented in Table 1 below.
Table I
DNS-OARC SOURCEPORTRANDOMNESSRATINGS
Rating Standard Deviation Great 3980 – 20,000+ Good 296 – 3980
Poor 0 – 296
The output of an example command is in the Figure2 below. dig @123.456.789.012 +short porttest.dns-oarc.net TXT
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"123.456.789.012 is POOR: 39 queries in 3.9 seconds from 39 ports with std dev 114"
Figure 2. Source Port Randomness Command Example Output
A simple script was generated, which would run similar commands to that outlined above for every unique dot IE name server. The port test server gave an empty or NULL response where a tested name server was not also acting as an
open recursive resolver. These NULL responses are indicated as “OK” in Table 2 below. Where the tested name servers were open and recursive, the port test server responded with results as exemplified in Figure 3 below.
DNS1.O2.IE, GREAT: 26 4.7 26 std dev 19966" DNS2.O2.IE, GREAT: 26 4.1 26 std dev 20207" dns1.dol.ie, GREAT: 26 4.1 26 std dev 20207" dns2.dol.ie, GREAT: 26 4.7 26 std dev 19966"
Figure 3. Source Port Randomness Script Output for Open Recursive Name Servers
The measurements undertaken were originally performed on May 25th 2010 and again on June 25th 2010. These measurements were repeated on January 13th 2011. A full list of dot IE second-level domain’s authoritative name servers were measured. As of Jan 13th 2011 154,657 domains name servers were probed, incorporating 12,298 unique authoritative name servers for second-level dot IE domains. The output of these measurements is presented in Table 2 below.
Table II
CACHEPOISONINGTHREAT TO DOTIE DOMAINS ON2011-01-13 Status Host Count Percentage
OK 362279 96.75 %
GREAT 8226 2.20 %
GOOD 215 0.05 %
POOR 3705 0.99 %
UNKNOWN 8 0.002 %
The analysis ascertained that nearly 3.24% of dot IE domains were delegated to name servers which were found to be open and recursive. Damas & Neves[6] recommend in their best common practice RFC paper that “In general, it is a good idea to keep recursive and authoritative services separate as much as practical.” Of those domains, 2.2% were found to be delegated to name servers which have a “GREAT” source port randomness (SPR) rating of 3980 – 20,000+. These name servers did not cause concern, as their SPR rating was high enough that a Kaminsky style attack would prove to be extremely difficult. Nonetheless, they were operating authoritative zones on open recursive name servers. Accordingly, they were categorised as vulnerable. 0.99% of dot IE domains were found to be delegated to name servers which were also acting as open and recursive resolvers and were determined as being highly vulnerable to the Kaminsky cache poisoning exploit. That is to say, following measurement, it was identified that servers in this category had a “POOR” rating, with a source port randomisation standard deviation of 0-296. Furthermore, 0.06% of the domains measured were found to be delegated to name servers that were also open recursive name servers, which had a “GOOD” SPR rating with a standard deviation of 296 – 3980. In advance of widespread deployment of DNSSEC throughout the Internet and as 3.24% of domains measured were found to be delegated to open recursive name servers, an analysis was undertaken to determine whether the operators of these name
servers had deployed up-to-date versions of vendors’ name server software. To achieve this, the same set of name servers used in the above SPR measurements were probed to elicit the version of name server software which were in operation. The name servers were probed usingfpdns,which was written by Roy Arends and Jakob Schlyter. The DNS-OARC lists fpdns as a very accurate DNS fingerprinting tool. It does not merely query for the banner version of a name server. The data generated displayed the number of unique name servers for each category of name server software version found. That is to say, that the calculations are not per domain, but rather per volume of usage for each version of name server software.
Table III
SECOND-LEVEL DOTIE DOMAINAUTHORITATIVEDNS FINGER
PRINTING
Name Server Version Host Count
ISC BIND 9.2.3rc1 – 9.4.0a0 6793
No match found 1780
ISC BIND 9.2.3rc1 – 9.4.0a0 [recursion enabled] 882
TIMEOUT 599
DJ Bernstein TinyDNS 1.05 555
bboy MyDNS 404
Host Not Found 368
JHSOFT simple DNS plus 141
PowerDNS PowerDNS 2.9.4 – 2.9.11 101 ISC BIND 9.2.0rc7 – 9.2.2-P3 94
ISC BIND 8.3.0-RC1 – 8.4.4 90
ISC BIND 8.3.0-RC1 – 8.4.4 [recursion local] 78 ISC BIND 9.2.0rc7 – 9.2.2-P3 [recursion enabled] 51 ISC BIND 9.2.3rc1 – 9.4.0a0 [recursion enabled 46 ISC BIND 8.3.0-RC1 – 8.4.4 [recursion enabled] 39
UltraDNS v2.7.0.2 – 2.7.3 34
Microsoft Windows DNS 2000 32
JHSOFT simple DNS plus [recursion enabled] 32 JHSOFT simple DNS plus [recursion enabled] 32
Nominum ANS 29
VeriSign ATLAS 22
ISC BIND 8.1-REL – 8.2.1-T4B [recursion enabled] 20
Cisco CNR 15
NLnetLabs NSD 1.0.3 – 1.2.1 14 ISC BIND 8.2.2-P3 – 8.3.0-T2A 9
TZO Tzolkin DNS 9
ISC BIND 8.2.2-P3 – 8.3.0-T2A [recursion enabled] 8 Dan Kaminsky nomde DNS tunnel 8
Sourceforge JDNSS 8
sourceforge Dents 5
PowerDNS PowerDNS 2.8 – 2.9.3 5 ISC BIND 8.2.2-P3 – 8.3.0-T2A [recursion local] 4
Microsoft Windows DNS 2003 4
incognito DNS commander v2.3.1.1 – 4.0.5.1 4 ISC BIND 9.1.0 – 9.1.3 [recursion enabled] 3 ISC BIND 9.2.0a1 – 9.2.2-P3 [recursion enabled] 3
NLnetLabs NSD 1.0 alpha 2
ISC BIND 9.1.0 – 9.1.3 1
ISC BIND 9.2.0rc4 – 9.2.2-P3 1 ISC BIND 9.2.0rc7 – 9.2.2-P3 [recursion local] 1
Mikrotik dsl/cable 1
Yutaka Sato DeleGate DNS 1
ISC BIND 8.4.1-p1 1
Microsoft Windows DNS NT4 1
With the knowledge of a target’s version of software, an attacker can easily ascertain the capacity of the target to withstand an attack. Older versions such as BIND 4 and BIND 8 could be considered as inappropriate for authoritative name
service, especially when they are also operating in an open recursive manner, as has been found above. Upon ascertaining that a small proportion of second-level authoritative name servers were also acting as open recursive resolvers and that they were found to have very low source port randomisation, an advisory was sent out to the name server operators indicating the risk posed. IEDR, the operator of the dot IE ccTLD considered the risk serious enough to warrant the issuance of an advisory as many high-profile domains were delegated to name servers in the most vulnerable categories. These high-profile domains included, critical infrastructure providers, financial institutions, regulators and high-profile businesses. The advisory was sent in May 2010, after the first measurement and again in June 2010 following the second measurement. While many name server operators took heed of the advisory, others were apathetic. There may be operational reasons which may explain why some servers run both authoritative and recursive name services on the same physical machine. Having said that, recursion should be limited to trusted parties and at a minimum, should not be open to anyone on the Internet. Within six months of Kaminsky’s publication, the multi-vendor patching response and the subsequent exploitation of a patched server by Polyakov, the IETF produced a new RFC standard entitled “Measures for Making DNS More Resilient against Forged Answers”[7]. Whilst the document is aimed at authors and programmers of resolvers, it reinforces the argument for deploying DNSSEC. It is explicit in its recommendations on what resolver authors should and must consider with regard to securing their software. Pending widespread deployment of DNSSEC, the RFC provides clear and unambiguous recommendations for resolver authors. Given that the standard was published in January 2009, it would be fair to assume that some of the larger DNS software vendors have taken the recommendations into consideration during their engineering efforts. It is out of scope for this paper to ascertain whether or not this is actually the case. However, name server administrators could consider evaluating their vendor’s compatibility with RFC5452[7] prior to an upgrade.
III. DNSSECANDPMTU ISSUES:OBSERVED IN DOTIE The objectives of the research undertaken in Section III of this paper are as follows. The intention was to measure and compare, the path maximum transmission unit (PMTU) of each source IP address as observed during packet traces at the dot IE authoritative name servers, with the EDNS0 buffer size (EBS) as announced in each query observed. This comparison was expected to yield contrasting values which may indicate the possibility of problems following the deployment of DNSSEC. While the problems are not directly attibutable to DNSSEC per sé, the increase in DNS packet sizes following DNSSEC deployment reveals CPE and SOHO equipment which may drop fragmented DNS datagrams. Frag-mented DNS datagrams are necessary as a consequence of increasing DNS packet sizes.
A. DNSSEC Increasing DNS Packet Sizes
During the development of the DNSSEC standards, re-searchers and internet scientists became aware of the propen-sity for larger packet sizes. Ager et al.[1] undertook a precise examination of the impact of DNSSEC signed queries and responses on zone files and packet sizes. The focus of their research was to ascertain the growth of packet sizes and the impact of such on CPU, memory and bandwidth. In their research, Ager et al. used packet traces recorded from their university campus resolvers, which they transformed to mimic the size of DNSSEC signed queries and responses. They asserted that the RRSIG resource record “adds 46 bytes plus key size plus zone name length” for a key generated using the RSA algorithm. A DNSKEY resource record would add 18 bytes plus the key size. A DS key, containing the child zone’s cryptographic hash of the child’s DNSKEY, would add 36 bytes. The NSEC resource record would add 23 bytes, plus name length, plus label length. They found the responses to queries with a status of “NOERROR”, would increase in packet size by a “factor of four”, whereas responses to queries with empty answers, or queries with a status of “NXDOMAIN”, were “bloated by a factor up to twelve” (Ager et al. 2006). Additionally, their research found that 77% and 72% of the NOERROR and NXDOMAIN responses would require IP fragmentation, either using UDP or TCP.
B. DNSSEC and PMTU
The availability of DNS data is imperative for internet-based communications. Osterweil et al. assert that this is a “two way street” in so far as a zone operator desires the confidence that their zone data is accessible or available[10]. Furthermore, resolver operators, usually in the form of ISPs, seek the assurance that their customers or users can obtain the DNS data they desire. To this end, Osterweil et al. set about defining “availability” in terms of DNSSEC with the objective of delivering empirical measurements on the deployment of DNSSEC. In doing so, they deployed a measurement framework to analyse the availability dispersion of DNSSEC enabled zones from disparate locations. Their measurements indicated that up to 20% of the 871 DNSSEC enabled zones had availability problems. This meant that a query for a zone from one location may be successful, whereas the same query from another location may fail. This inconsistency in DNSSEC resolution would obviously be catastrophic for the deployment initiative, if unchecked. Osterweil et al. found that the dispersion was due to what is known as Path Maximum Transmission Unit (PMTU) problems. With an awareness of the increasing size of DNS packets which are DNSSEC enabled, Osterweil et al. 2008 designed a measurement framework which undertook an analysis of the precise cause of the PMTU problems. During their analysis, if a query response was not received, their pollers initiated a binary search of the smallest packet size that would be accepted on the problem path. They called that process “PMTU exploration”.
Osterweil et al. 2008 found that one of their five pollers attempted seven times as many PMTU explorations as the others and that “over 20% of the PMTU problems result in data that could not be retrieved by UDP (no matter what the packet size is specified)”. The implications of such inconsistencies in the resolution of DNS enabled with DNSSEC are obviously serious. Osterweil et al. noted that the research of Åhlund & Wallström [2] and Bellis & Phifer [3] had found that the developers of some Consumer Premises Equipment (CPE) such as SOHO broadband routers assumed the UDP packet size specification of less than 512 bytes from the earliest DNS standard specification of Mockapetris[9]. The widespread usage of CPE and SOHO equipment with misconfigurations or incorrect protocol assumptions may have a significant impact on the successful deployment of DNSSEC in an Irish context. The following sections of this paper evaluate potential problems which may
occur following DNSSEC deployment in Ireland.
C. Methodological Framework
International research carried out in the Netherlands by scientists in the RIPE NCC Labs, asserted that the introduction of DNSSEC signed zones would introduce problems in specific circumstances[8]. This research examines this potential in Ireland. The methodological framework used throughout was highly structured and was based upon quantitative techniques which disseminated raw binary data into discrete data. These discrete data were analysed with the objective of ascertaining if problems may arise following the deployment of DNSSEC in Ireland. Subsection D sets the context by presenting the development of the instruments through which the collection of the primary data was carried out. It continues with a description and details of the development and design of the instruments, which were used to prepare the raw data. Subsection E describes the use of the deployed instrument which facilitated the analysis of the primary data and processes by which these data were extrapolated into discrete data sets. In turn, these data sets enabled subsequent analysis culminating in evidence of potential problems arising out of the deployment of DNSSEC in an Irish context.
D. Instrument Development
Figure 5, on the page 5, is an illustration of the instrument framework which was developed to facilitate the data collection for a part of the research undertaken in this paper. The graphics at the top of the diagram marked “Stub Resolver” represent the querying clients which would initiate sending a DNS query for a given domain. A stub resolver is a resolver that relies on a recursive name server to complete the name resolution service on its behalf. So these stub resolvers are unable to resolve domains on
their own. They pass off this work to a recursive resolver. The resolvers in Figure 5 provide full name resolution services for the stub resolvers querying the root, TLD and authoritative servers for a given domain. In this example, during the process of resolution, they must query one of the authoritative domain name servers for a .IE domain. In doing so, the queries received by the TLD authoritative name servers were observed using the tcpdump software. The DNS packets were observed ‘on the wire’ as the data passed through each server’s ethernet interface. The data collected were written to packet capture (pcap) files at selected intervals. This above example command writes to a file pre-pended with the server name on which the collection is occurring, along with the date and time of collection. It captures all tcp and udp data observed on port 53. Port 53 is the reserved port number for the domain name system. The tcp protocol is specified, in the command above, as DNSSEC may require support through the extensions provided for in EDNS0 which facilitate truncation of query responses for larger signed DNS responses. According to Conrad[5] “DNS UDP datagrams are limited to 512 bytes [RFC1035], responses including DNSSEC security RRs have a high probability of resulting in a truncated response being returned and the resolver retrying the query using TCP.”
The graphic at the bottom of Figure 5, below,
represents the server which was set up to collect
the primary data from each of the name servers
banba.domainregistry.ie (master) and b.iedr.ie (slave). NLnet Labs, the developers of the NSD and Unbound name server software, have also developed a library of various DNS related tools to assist in DNS programming, one of which is ldns-dpa. Ldns-dpa is a DNS packet analyser using IP trace files. Libdns was installed on the collector node. Proprietary shell scripts were written to process the pcap files in conjunction with the ldns-dpa software, culminating in the output of discrete data sets.
E. Evaluating the queries which have the ‘DO’ bit set. Pcap files were collected every day, for a four month period. Each pcap file was evaluated for DNS packets where the query response (qr) bit was set to zero and the DO bit was set to 1. This search would return a count of the DNS packets which were queries to the server where DNSSEC support was requested. It is important to note that the packets which were query responses from the server (qr=1), were not evaluated. An example of such commands can be seen in the grey box below:
F. Measuring the MTUs for Resolver Addresses.
A network path is a sequential set of links between network nodes in which links are limited in their capacity to support
Figure 4. Instrument Framework.
ldns-dpa “$FILE” –f “edns=1&qr=0&do=1” –of edns.tr ldns-dpa edns.tr –u edns-packetsize | awk ‘{ print $3, $4 }’ Figure 5. Extracting DNSSEC Enabled Queries
packets of a certain size. This is known as the maximum transmission unit or MTU. The smallest MTU for a network path is known as the Path Maximum Transmission Unit or PMTU. This analysis set about identifying and measuring the actual maximum transmission unit (MTU) for the IP addresses of the resolvers identified in the data sets of each name server. The DNS-OARC reply size test server was used for these measurements. The DNS-OARC or Domain Name System Operations Analysis and Research Center, modified a DNS server into a reply size test server. “DNS-OARC built the DNS Reply Size Test Server to help users identify resolvers that cannot receive large DNS replies.”[12]. The OARC reply size server works by sending DNS replies, which decrease in size in a logarithmic manner, to the IP address specified to the OARC reply size test server. Wessels[12] explains “the server uses something akin to a binary search to refine the reply size limit. For example, if the first step indicates that the limit is between 1024 and 2048, then the next step will send a number of logarithmically-stepped responses between that range (2048, 1625, 1290, 1024). At the end a TXT RR is sent indicating the measured reply size limit.”
The analysis was performed on all pcap files for
queries with EDNS0 support, of which a more detailed analysis was performed to establish the path maximum transmission unit (PMTU) size of all such queries. The analysis of such data would assist in establishing the percentage of queries from resolvers which requested DNSSEC support, but which may encounter transmission
problems through a given network path sequence.
as described in the above subsections, was undertaken. This facilitated the measurement of the maximum transmission units for all resolver addresses, as identified in the measured data set, from March 15th 2010 through July 15th 2010. The pcap file data were further filtered, with the
objective of identifying each EDNS buffer size
category. The source IP addresses and the EDNS buffer size (EBS) categories were recorded for evaluation
later. The sizes ranged from 512 to 4096 bytes.
The source IP addresses PMTU were measured using the DNS-OARC reply size test server.
dig @109.105.130.33 +short rs.dns-oarc.net txt >> pmtu.out; dig @109.106.1.2 +short rs.dns-oarc.net txt >> pmtu.out; dig @109.106.1.3 +short rs.dns-oarc.net txt >> pmtu.out; dig @109.106.192.3 +short rs.dns-oarc.net txt >> pmtu.out; dig @109.106.204.3 +short rs.dns-oarc.net txt >> pmtu.out; dig @109.107.25.6 +short rs.dns-oarc.net txt >> pmtu.out;
Figure 6. Extract from banba.domainregistry.ie reply size test script.
The responses from the OARC reply size test server were recorded for comparison with the EBS figures.
;; connection timed out; no servers could be reached rst.x3827.rs.dns-oarc.net. rst.x3837.x3827.rs.dns-oarc.net. rst.x3843.x3837.x3827.rs.dns-oarc.net.
"109.121.255.42 DNS reply size limit is at least 3843" "109.121.255.42 sent EDNS buffer size 4096" "Tested at 2010-04-30 16:17:59 UTC" ;;
connection timed out; no servers could be reached Figure 7. Extract from “pmtu.out”
The figures at the end of the line “DNS reply size limit is at least” were the measurements which were of interest. These figures were extracted for comparison with the EBS figures.
G. Comparison of the EBS and MTU data.
The data observed and measured in sub-sections E and F were compared and the IP addresses where the EBS and MTU did not match were reported on. These data are presented in figures 9 & 10 below.
IV. ANALYSIS
The “+” signs on the Figures 8 and 9 above represent the categories of variability of the EDNS0 buffer size (EBS) and the measured buffer size or MTU. That is to say, that not every measurement is displayed above, but rather the
Figure 8. banba.domainregistry.ie comparison of EBS Vs MTU measured.
Figure 9. b.iedr.ie comparison of EBS Vs MTU measured.
combinations of EBS and MTU, e.g. (512, 512) (512,1387). The markings on Figures 8 and 9, which are above the diagonal light blue dotted line, indicate that the instruments measured larger buffer sizes when compared to that which the resolvers announced in their query using EDNS. This is problematic, as it would cause the server to truncate the responses returned to the resolver being unnecessary otherwise. Furthermore, truncation may cause retries using TCP increasing bandwidth usage. However, the resolver would receive a full and timely answer. The markings on Figures 8 and 9, which are below the diagonal light blue dotted line, indicate that the instruments measured smaller buffer sizes as compared to that which the resolvers announced in their query. Furthermore, the measured buffer size capacity is less than what their resolver claims to be capable of handling. These resolvers that have an EBS that is greater than
the MTU are critical, because with the deployment of DNSSEC, query responses will get larger for signed zones. Specifically, cryptographic key information would be sent by the authoritative server in the responses to such queries. The inclusion of the cryptographic key information in the DNSSEC RRs would increase the query response packet size and therefore, the query response would never arrive at the resolver. Consequently, given a situation where a resolver does not receive a response to a query, the resolver would resend the query, increasing the query rate of both resolver and TLD server. This has implications for increased bandwidth and consequently costs. Ultimately, this problem would cause delays and potentially timeouts. Given that the variability of EBS compared with MTU could be critical, it is appropriate to question where responsibility lies. This paper asserts that the responsibility is outside of the control of any one entity, particularly a TLD administrator. Figure 10 on the following page provides the evidence to support that assertion. It does so by using the data identified in Figures 8 and 9 above, to illustrate the geographical distribution of the IP address which were identified as critical. In particular, the EDNS0 buffer size (EBS) and MTU pairs which were plotted below the blue diagonal line in Figures 8 and 9. The geographical distribution and the variability of the EBS to MTU figures illustrate that the PMTU issues alluded to this paper, are outside the control of any one entity. Figure 10 below was created to illustrate the geographical distribution of EBS and MTU variability or the DNSSEC PMTU problem. The geographical location of the IP addresses was identified using GeoIP software. GeoIP identifies the country of origin of a given IP address including the longitudinal and latitudinal coordinates. The IP addresses and associated country records were subsequently recorded in the database used throughout this research.
Figure 10. DNSSEC PMTU Problems Per Country
Obviously, potential DNS response timeouts would have service ramifications which must not be ignored. These problems are not directly attributable to DNSSEC per se, but moreover attributable to mis-configured stub
resolvers, recursive resolvers and other middleware devices such as firewalls. If the assertion was that
DNSSEC caused problems, then the validity of the
research may be threatened through its causal direction. The research undertaken in this paper has applied a rigorous, deductive approach to the methodology on which this research has been based. The hypotheses are adaptations of research undertaken in an international
context by acclaimed DNS researchers. The
meta-theories posited throughout this paper have arisen out of the rigorous, quantitative, deductive approach and have been applied and proven in the context of Ireland. It is important to note that PMTU measurements of the resolvers referred to in section 4 F above, was in a delayed context. That is to say, that there was a time delay between the point in time when the client or resolver issued the query to each name server node and the point in time that the PMTU measurements were carried out. This is considered a limitation and acceptable, but is not considered a logic leap or an incorrect assumption.
V. CONCLUSIONS ANDFUTUREWORK
The research undertaken throughout this paper has given an indication of where and how DNS vulnerabilities may arise in an Irish context. Care has been taken to alert the responsible operators of infrastructure which may be at risk. Apathy has been encountered to a small extent. However, the alerts may go some way to improving the quality of the ccTLD name space by striving to improve the quality of authoritive name service which dot IE domains are delegated to. Nonetheless, IEDR acting as the manager of the dot IE ccTLD registry, will continue to measure DNS vulnerabilities in a similar manner with the overall objective of ensuring the security of the domain. IEDR intend to deploy DNSSEC for the dot IE ccTLD in the third quarter of 2011. This research has outlined some possible problems which the deployment of DNSSEC may reveal in an Irish context. To assist in overcoming these issues, an Irish DNSSEC Task Force has been launched with a view inviting appropriate parties to contribute in the deployment of DNSSEC in Ireland. In that effort, the issues with CPE and SOHO equipment will be conveyed and hopefully overcome where simple upgrades are the solution.
The research of Åhlund & Wallström [2] and Bellis & Phifer [3] set about determining the impact of DNSSEC on CPE and SOHO equipment. They found that many CPE and SOHO devices were incompatible with DNSSEC. Their research was conducted in 2008. It may be worthwhile updating and building upon that research.
APPENDIXA FIRST APPENDIX
REFERENCES
[1] B. Ager, H. Dreger, and A. Feldmann. Predicting the DNSSEC overhead using DNS traces. In Information Sciences and Systems, 2006 40th
Annual Conference on, pages 1484 –1489, March 2006.
[2] Joakim Ahlund and Patrik Wallstrom. Dnssec - tests of consumer broadband routers. http://bit.ly/gaH9zp, 2008.
[3] Ray Bellis and Lisa Phifer. nominet dnssec broadband test -google search. http://download.nominet.org.uk/dnssec-cpe/DNSSEC-CPE-Report.pdf, 2008.
[4] CERT-US. US-CERT vulnerability note VU#800113. http://www.kb.cert.org/vuls/id/800113, 2008.
[5] D. Conrad. Indicating resolver support of DNSSEC. RFC 3225, 2001. [6] J. Damas and F. A. C Neves. Preventing use of recursive nameservers
in reflector attacks. RFC 5358, 2008.
[7] A. Hubert and R. van Mook. Measures for making DNS more resilient against forged answers. RFC 5452, 2009.
[8] Daniel Karrenberg, René Wilhelm, and Wolfgang Nagele. Measuring DNS transfer sizes - first results | RIPE labs. http://labs.ripe.net/content/measuring-dns-transfer-sizes-first-results, 2010.
[9] P.V. Mockapetris. Domain Names - Implementation and Specification. RFC 1035, 1987.
[10] Eric Osterweil, Michael Ryan, Dan Massey, and Lixia Zhang. Quantify-ing the operational status of the DNSSEC deployment. InProceedings of the 8th ACM SIGCOMM conference on Internet measurement, pages 231–242, Vouliagmeni, Greece, 2008. ACM.
[11] P. Vixie. Extension Mechanisms for DNS (EDNS0). RFC 2671, 1999. [12] Duane Wessels. OARC’s DNS reply size test server | DNS-OARC.
