New gTLD Security, Stability, Resiliency Update ...techreports.verisignlabs.com/docs/tr-1130008-1.pdf · New gTLD Security, Stability, Resiliency Update: Exploratory Consumer Impact

New gTLD Security, Stability, Resiliency Update: Exploratory

Consumer Impact Analysis

[Verisign Labs Technical Report #1130008 Version 1.1]

Eric OsterweilVerisign

Matt ThomasVerisign

Andrew SimpsonVerisign

Danny McPhersonVerisign

August 22, 2013

1 Introduction

Interesting times await those who rely on something,and at once cannot imagine it failing. For example, werely on the Domain Name System (DNS) [47] for al-most everything we do online. We often pay little atten-tion to this seemingly simple system because it mostly“just works,” and it has been working for more than 30years. We count on it to always be highly available, butsome recent developments in the DNS ecosystem suggestthat we might have begun to mistake its stability andubiquity for unbounded robustness and flexibility. Onemight argue that the DNS has fallen victim to a famouscurse, pronounced by Mark Weiser,

“The most profound technologies are those that dis-

appear.”

These sage words suggest much, but also imply thefate that we often inherently overlook important aspectsof those technologies that we depend on the most.

Consider what might happen if overnight, some net-worked systems inside a healthcare provider in Japanbegan to suffer undiagnosed system failures. Would itbe a concern if some installations of banking softwarein the islands of the Caribbean became non-responsive?Perhaps pause would be warranted when embarking ona visit to a developing nation, and discovering that thehotels in the region have suffered outages of their reser-vation systems. What if a rash of major enterprisesaround the world began suffering from widespread net-worked system failures of their internal operations (pay-roll, benefits, VoIP systems, etc.)? What if voice com-munications for home users became impacted by disrup-tions? Are specially branded names actually less securethan they were under more innocuous naming schemes?All of these scenarios have a measurable dependence onthe DNS, and our measurements suggest they might alsohave a measurable dependence on the lack of certaingeneric Top Level Domain (gTLD) strings being dele-gated from the DNS root zone.

In 2011, the Board of the Internet Corporation for

Assigned Names and Numbers (ICANN) [2] voted torelease a document called “The New gTLD ApplicantGuidebook.” In some ways, this formally heraldedICANN’s intention to allow private parties to apply for,and add, multitudes of new gTLDs to the root zone.It is noteworthy that before this, the DNS root zonebarely grew at a snail’s pace. Additions of new TLDswere infrequent. While this was not a mechanical limita-tion (delegations could certainly be allocated at a muchgreater pace), this was a matter of maintaining stabil-ity. As noted in an open letter to ICANN [45], the me-chanical capability to delegate a vast quantity of newgTLDs exists, but using this facility could underminethe stability of the DNS ecosystem. A response to [45]was sent from the U.S. Department of Commerce’s Na-tional Telecommunications and Information Adminis-tration (NTIA) [38], in which the NTIA questioned thedistinction between the current ability to expedite del-egations with the advisability of such an action, eventhough multiple organizations have issued specific ad-vice around this distinction for quite some time. Infact, in 2005, the National Research Council releaseda report with findings from a study called, “Signpostsin Cyberspace,” [48] whose goal was to extensively ex-amine a number of issues surrounding the DNS’ globalecosystem, including its stability and growth. Amongthe findings of this report was advice on cautious growthof gTLDs:

Considering technical and operational per-formance alone, the addition of tens ofgTLDs per year for several years poses min-imal risk to the stability of the root. How-ever, an abrupt increase (significantly beyond thisrate) . . . could have technical, operational, eco-nomic, and service consequences that could affectdomain name registrants, registries, registrars, andInternet users.

. . .

If new gTLDs are added, they should be addedon a regular schedule that establishes themaximum number of gTLDs (on the order

1

2 HOW WE USE THE DNS

of tens per year) . . . Addition of gTLDs shouldbe carried out cautiously and predictably, so thaton the one hand, the stability and reliability of thesystem can be protected, and on the other hand,those considering acquiring a gTLD can do so witha realistic view of future prospects.

A mechanism to suspend the addition of

gTLDs in the event that severe technical or

operational problems arise should accompany

a schedule of additions. It should explicitly

specify who has the authority to suspend ad-

ditions and under what conditions.

Much of this advice remains unresolved by ICANN[44, 42], despite reiteration of caution from ICANN’sown Security and Stability Advisory Committee(SSAC) [19, 40, 41, 43], as well as industry [16, 53]. Ina recent technical report [16], we cataloged unresolvedissues in the new gTLD program’s roll-out, issues uponwhich we believed the security, stability, and safe intro-duction of new gTLDs is predicated.

To augment that work, in this study we evaluate therisks that are about to be transferred onto Internet usersby the introduction of as many as one thousand newgTLDs (in the first year, alone). To evaluate the “risk,”we propose a novel set of measures that represent ac-tual risks to end users, and illustrate their incidence bymeasuring operational threat vectors that could be usedto orchestrate failures and attacks. We present our can-didate quantification in the form of a Risk Matrix, andillustrate one possible way to interpret its results. Whatwe find is that while some may claim that the relativelyabrupt addition of over one thousand new gTLDs is nota concern, there are quantifiable signs that profound dis-ruptions might occur if the current deployment trajec-tory is followed. This may be especially true if recom-mendations that have been made are not fully resolved.For example, we investigate issues that include Man inthe Middle (MitM) attacks, internal Top Level Domain(iTLD) collisions with applied for gTLD strings, X.509certificate ambiguities, and regional affinities that couldresult in collateral damage to unsuspecting regions. In-deed, our measurements suggest that there may be mea-surable dependencies for undelegated gTLD strings of.accountant in the U.S. Virgin Islands, .medical inJapan, .hotel in Rwanda, and .corp across many topo-logically distributed Autonomous Systems (ASes)1 inthe Internet. We also find evidence that there mayexist a dependency between a popular Small Office /Home Office (SOHO) router vendor’s SIP boxes andthe applied-for gTLD string .box. What’s more, withthe intention for some applied-for gTLD strings, suchas .secure, to function as “‘secure neighborhoods’ onthe Net” [39] , our risk matrix suggests that their se-

1Including multiple constituent enterprises, in cases whereASes aggregate or provide connectivity for multiple clients.

mantic meaning opens them up to risk factors from cur-rent traffic that other, lower profile strings don’t startoff with. For illustrative purposes, throughout this pa-per, we consider what specific risk factors can be mea-sured to show that delegations under applied-for gTLDstrings like .secure represent demonstrably riskier pro-files than they would have under a gTLD that existstoday.

The remainder of this paper is structured as follows:Section 2 describes some of the (potentially surprising)ways in which Internet-based systems interact with theDNS today. Next, in Section 3, we describe the gen-eral measures we use to quantify “risk.” With that, wediscuss our measurements in Section 4, and use thoseresults to motivate our Security Analysis in Section 5.This frames some recommendations in Section 6, beforewe conclude in Section 7.

2 How We Use the DNS

Part of the DNS’ central role in our online lives is thatits intricacies and the complex ways that we use it cancause it to slip from the forefront of our attention. Wemay take for granted that resolving a resource (such as amail server’s service address) for company.example.commay require multiple round trips to global resources inorder to locate the name servers of several private com-panies before an email transaction can even be initiatedwith the mail server itself. As an Internet-scale feder-ated multi-administered database, the DNS is one of akind. Issues arise, such as transitive trust [50, 55] (whereresolving a simple DNS domain name could involve DNSresolution of hundreds of other DNS domain names), tocomplications stemming from deploying DNS SecurityExtensions (DNSSEC) [20, 51], to issues in managingthe DNSKEY Resource Record set (RRset) [52, 49], andmore.

Growth Has Been Slow: It should come as littlesurprise that modifications to the DNS (whether theybe its protocol, its name space, or even the service lo-cations of its root name servers) have always been doneat a careful pace. There is a multitude of advice fromexperts that advocate this conservative approach, in-cluding the aforementioned 2005 Nation Research Coun-cil report [48] and the subsequent Scaling the Root re-port [19], in 2009. Indeed, Figure 1 shows some of therelative growth that the DNS root has undergone sincelate 1999. Note the relatively flat line of TLD growth(representing slow growth in the number of TLDs), es-pecially relative to the larger growth of various ResourceRecord (RR) types. As we reported in some of our previ-ous work [17], the growth rate of the root zone has beenfairly modest over the past 14 years, adding only 66 newTLDs since 1999 (45 of which are internationalized do-

c©2013 VeriSign, Inc. All rights reserved. 2 Verisign Labs Technical Report #1130008 version 1.1


main names, or IDNs). As part of the Root Zone Main-tainer (RZM) role, Verisign maintains the authoritativedatabase containing the root zone data for distributionto all the root servers. Figure 2 illustrates changes inthe root zone over the past 61 months. Between Juneof 2008 and June of 2013 there were 1,446 total changes(about 0.8 changes/day, on average), adding only 37 netnew TLDs.

To build on these measurements, we can examinequery volumes for some of the TLDs that were addedto the DNS root before and then after they were ac-tually delegated, and try to assess any relative impact.Specifically, Table 1 enumerates traffic volumes for sev-eral TLDs (some country code TLDs, ccTLDs, and somegTLDs) before they were delegated from the DNS root.Suffice it to say, after these TLDs were delegated, therewas relatively little collateral damage reported to sys-tems throughout the Internet. To contrast this, usingdata collected in Day In The Life (DITL) of the Inter-net data [24], some of the query volumes for currentlyapplied-for gTLD strings are shown in Table 2. One cansee that many of the currently applied-for strings actu-ally have lower traffic volumes than those in Table 1.This could indicate that there is nothing to worry aboutwhen adding new TLDs, because there was no globalfailure of DNS when this was done before. Alternately,one might conclude that traffic volumes are not the onlyindicator of risk, and the semantic meaning of stringsmight also play a role. We posit that in some cases,those strings with semantic meanings, and which are incommon use (such as in speech, writing, etc.) pose agreater risk for naming collision. In fact, what we willshow is that the semantic meanings of strings appearto play a large role in how they are used, and there isevidence that suggests that the traffic volume is not theonly indicator of risk.

Dependence on Ossification: Indeed, while the rel-ative stability, and cautious growth, of the DNS rootzone has helped stewards safeguard its stability and op-erational security, it is not always clearly recognized thatthis ossification has had other effects as well. Specif-ically, there are ways in which this slow change hasresulted in a form of inflexibility. For example, someRFCs [30, 26] expect that certain strings will not bevalid DNS TLDs, and suggest that administrators canconfigure them as iTLDs in their networks. In addi-tion, some system administration manuals [3, 1, 5, 54]also suggest that Local Area Networks (LANs) shouldconfigure iTLDs as local DNS TLDs for strings that donot exist in the DNS. Some examples include .corp,and .dev (both applied-for strings), and even .novell.The intuition behind this advice is that locally scopedbusiness-centric domains (like .dev, .corp, .mail, etc.)are all user-friendly mnemonic labels that are easier toreference, and the implication of the advice could be

TLD PPM

XXX 4018ASIA 2708KP 2588AX 2369TEL 1593UM 836CW 543POST 388SX 331

Table 1: This Table shows a measurement of traffic seenfor TLD strings in January 2006. The measurement oftraffic is in Parts Per Million (PPM), and that can beinterpreted as “the number of queries seen for a givenstring for every 1,000,000 total queries.” One PPM isessentially a very small fraction of a percent. For ex-ample, .com generally gets about 200,000 PPM to theroots.

New gTLD PPM

HOME 27855CORP 4085ICE 511GLOBAL 355MED 341SITE 299ADS 297NETWORK 260GROUP 249CISCO 238BOX 222PROD 187IINET 167MAIL 162DEV 154HSBC 149

Table 2: This Table shows a measurement of traffic cur-rently being seen for newly applied-for gTLD strings,again in PPM.

read as they will never exist in the DNS. Moreover,some advice to use these strings as iTLDs is intendedto help DNS resolution to continue for internal systemsin the event of a disruption of online connectivity. Thatis, Fully-Qualified Domain Names (FQDNs), tethered tothe availability of the global DNS, may be problematicif network connectivity issues exist at a given site or lo-cation, or if complete operational autonomy is desired.The intuition for this advice is: If a network or orga-nization becomes partitioned from the Internet, usingiTLDs can help preserve networked business operations;



Figure 1: This Figure uses DNS-OARC data to plot the growth of various DNS RR types in the root zone, overtime. The green line represents the very modest growth of new TLDs being added over the past 15 years.

6

28

21

46

34

7

66

10

22 24

20 17 20

31

7

14

21

12

22 19

7

26

17

22

38 39

45

60

24

22 22 22

40

26

13

23

44

12

20 19

39

42

37

17

24

11

24

22

25 28

18

16 13 13 12

6

18 18

32

22

21

0

10

20

30

40

50

60

70

Jun-

08

Aug-08

Oct-

08

Dec-08

Fe

b-09

Apr

-09

Jun-

09

Aug-09

Oct-

09

Dec-09

Fe

b-10

Apr

-10

Jun-

10

Aug-10

Oct-

10

Dec-10

Fe

b-11

Apr

-11

Jun-

11

Aug-11

Oct-

11

Dec-11

Fe

b-12

Apr

-12

Jun-

12

Aug-12

Oct-

12

Dec-12

Fe

b-13

Apr

-13

Jun-

13

Tota

l Cha

nges

Total Root Zone Changes June 2008 to June 2013

Figure 2: This Figure illustrates the total root zone changes from June 2008 to June 2013.



else alternative workarounds may need to be considered.However, many of those iTLD strings are now applied-

for gTLDs. This could mean that corporations that arealready depending on these iTLDs not being globally re-solvable (as gTLDs) may suffer resolution failures forsome of their internal services. Clearly, though, onemight ask whether internal DNS queries should even beseen outside a corporation’s network. That is, if there isan iTLD .corp, why would one expect queries to be sentto the global DNS root? The answer is a nuance thateven many seasoned system administrators are surprisedby (even though it has been a standard behavior of DNSfor some time): DNS resolvers may apply search list pro-cessing and try the global DNS root first! RFC 1535 [35]outlines this problem, and a recent Internet-Draft [46]illustrated (in its Section 2.1) that DNS search list in-teractions result in queries being sent to the DNS rootbefore being resolved internally.

In fact, this issue was so fundamental to the wayDNS works, that ICANN’s SSAC provided this advicein SAC045 [40] in 2010:

Recommendation (1): The SSAC recom-mends that ICANN promote a general aware-ness of the potential problems that may occurwhen a query for a TLD string that has his-torically resulted in a negative response beginsto resolve to a new TLD. Specifically, ICANNshould:

• Study invalid TLD query data at the rootlevel of the DNS and contact hardwareand software vendors to fix any program-ming errors that might have resulted inthose invalid TLD queries. . . .

• Contact organizations that are associatedwith strings that are frequently queriedat the root. Forewarn organizations whosend many invalid queries for TLDs thatare about to become valid, . . .

• Educate users so that, eventually, privatenetworks and individual hosts do not at-tempt to resolve local names via the rootsystem of the public DNS.

Recommendation (2): The SSAC recom-mends that ICANN consider the following inthe context of the new gTLD program.

• Prohibit the delegation of certain TLDstrings. RFC 2606, “Reserved Top LevelDomain Names,” currently prohibits a listof strings, including test, example, in-valid, and localhost. ICANN should co-ordinate with the community to identify amore complete set of principles than theamount of traffic observed at the root as

invalid queries as the basis for prohibit-ing the delegation of additional strings tothose already identified in RFC 2606.

• Alert the applicant during the string eval-uation process about the pre-existence ofinvalid TLD queries to the applicant’sstring. . . .

• Define circumstances where a previouslydelegated string may be re-used, or pro-hibit the practice.

These recommendations were meant to protect twosets of stakeholders. The first and most obvious withinthe ICANN community was the new gTLD applicants,those who would be associated in some manner withthe operations of registry infrastructure supporting newgTLDs. In response to these recommendations, ICANNdid reserve a number of strings. Table 3 is taken fromSection 2.2.1.2.1 Reserved Names of ICANN’s Appli-cant Guidebook [10], and represents the strings thatare prohibited as of June 2012. Table 4 enumeratesthe amount of query traffic seen for each of these re-served gTLD strings (in PPM). When contrasted withthe query rates seen in Tables 1 and 2, this Table sug-gests that the traffic volume to these reserved stringsis relatively negligible. Of note is the fact that the listof reserved names in RFC 2606 [30]: .test, .example,.invalid, and .localhost (updated by RFC 6761 [27])all see a reasonably large number of queries at the root,and were included in Table 3. More importantly, whilethere is no discernible risk-based metric for inclusionin the current reserved names table, there is an abun-dance of ICANN-associated entities, to which our mea-surements suggest either very low or no discernible riskexists. Yet, in contrast, there is an obvious absence ofpotentially problematic strings, such as those discussedin SAC045 [40], and in Appendix G Private DNS Names-paces of RFC 6762 [26]. Furthermore, there seems to beno indication that any of these strings were added basedon measurements, as recommended.

Scoping: An additional way in which new gTLDstrings can be problematic is in software that hasmade implicit assumptions about which strings arevalid TLDs, and the authority structure of the DNS.Consider when a Web browser receives a cookie froma website, such as www.example.com, and then visitssubzone.example.com. The browser will protect thescope of the cookies, the X.509 certificates that can beused, etc. This protection is implemented through aglobal list (maintained at http://publicsuffix.org/)that details the administrative boundaries of the DNS.It allows Web browsers to determine where various ad-ministrative boundaries exist, and discusses issues like“Super Cookies” (described below). Currently, browsers(and other relying party software) download this static


3 GAUGING THE “RISK” LEVEL FOR NEW GTLD STRINGS

AFRINIC IANA-SERVERS NROALAC ICANN RFC-EDITORAPNIC IESG RIPEARIN IETF ROOT-SERVERSASO INTERNIC RSSACCCNSO INVALID SSACEXAMPLE* IRTF TEST*GAC ISTF TLDGNSO LACNIC WHOISGTLD-SERVERS LOCAL WWWIAB LOCALHOSTIANA NIC

Table 3: *Note that in addition to the above strings,ICANN will reserve translations of the terms “test” and“example” in multiple languages. The remainder of thestrings are reserved only in the form included above.

PPM TLD Reserved By

66963.9 LOCAL IETF12023.7 LOCALHOST IETF1740.6 INVALID IETF432.7 TLD IETF137.7 TEST IETF45.7 WWW IETF30.2 EXAMPLE IETF10.1 NIC ICANN5.0 GAC ICANN1.8 NRO ICANN0.7 ASO ICANN0.2 WHOIS ICANN0.2 IAB ICANN0.1 IANA ICANN0.0 RIPE ICANN0.0 ARIN ICANN0.0 ROOT-SERVERS ICANN0.0 IESG ICANN0.0 IETF ICANN0.0 ALAC ICANN0.0 SSAC ICANN0.0 APNIC ICANN0.0 ICANN ICANN0.0 GTLD-SERVERS ICANN0.0 INTERNIC ICANN0.0 GNSO ICANN0.0 IRTF ICANN0.0 RFC-EDITOR ICANN0.0 ISTF ICANN0.0 LACNIC ICANN0.0 AFRINIC ICANN

Table 4: This Table shows the amount of traffic (inPPM) for each of the reserved gTLD strings, and whichorganization reserved the string (the Internet Engineer-ing Task Force, IETF, or ICANN).

file (often at compile time) and then “bake it into” theircode. As the DNS delegation structure evolves (admin-istrators subdivide their zones, aggregate their zones,transfer their zones, etc.), the maintainers of this listmust struggle to keep its contents current with the state

of the global DNS delegation structure. On top of that,as browsers and other software age, their compiled ver-sions of the list becomes more out of date.2 A numberof issues have been reported as a result of this, and wediscuss these more in Section 3.1. The suffix list is alsoused to protect cookies shared between different hostsby not allowing Super Cookies to be set for high leveldomains, such that cookies can be valid for example.combut not for all .com in general.

Now consider, for example, the new gTLD string.secure [21], which has been called a “‘safe neigh-borhood’ on the Net” [39]. The plan for this newgTLD is to offer a branch of the DNS that requiresits registrants to have a pronounced security posturethrough deploying enhanced security precautions, be-ing subject to security scans, and more; all in thevein of conveying greater faith in the security of thedomains under this gTLD to end users. Now, sup-pose a user connects to www.〈someSite〉.secure, andthen to 〈partner-association〉.〈someSite〉.secure.Here, the various parties involved are all implicitlytrusting that browsers will not allow separate orga-nizations to share cookie information or other cross-administrative data. Moreover, the same infrastructuremust ensure that when an HTTPS connection is made to〈partner-association〉.〈someSite〉.secure that anyX.509 certificate that may already exist (or even thosethat might be issued in the future [43]) for the .secure

string (an Internal Name Certificate) cannot be used(similar to a Super Cookie) to impersonate any actualInternet property below .secure. In such a case, aMitM attack could be successfully launched.

The qualitative liabilities could be seen as a generalcaution, but rather than debating the possible degreeof exposure, we have created a measurement-based ap-proach to codifying one possible example of “risk” toend users and networked systems, which we motivate inSection 3.

3 Gauging the “Risk” Level forNew gTLD Strings

Previous studies of the DNS root have noted largeamounts of invalid queries [23, 60]. While many queriesmay not result in positive answers, we contend that thisdoes not necessarily mean they are “invalid.” Specif-ically, we have found indications that many of thesequeries are likely valid, in some way. For example, whena user clicks on a link that points to a domain nameunder an applied-for gTLD string (either mistakenly, orbecause the domain name is meant to resolve internally),the resulting query is “valid” and can pose a direct risk

2A partial list of software that uses this suffix list is maintainedat http://publicsuffix.org/learn/ .


3.1 The Past is Prologue 3 GAUGING THE “RISK” LEVEL FOR NEW GTLD STRINGS

to that user. To illustrate the seriousness of the risksposed to the end user, we begin by detailing a few illus-trative examples.

3.1 The Past is Prologue

Constructing hypothetical risks and attacks is a commonpractice among operational security professionals. How-ever, some have noted that this can be an unboundedexercise that reaches a point of diminishing returns. We,therefore, outline several instances of similar and analo-gous cases here, and observe that the type of behavior inthese examples would likely get easier with the inflationof the number delegated gTLDs.

To illustrate what can happen when a namespace thatis assumed to be non-delegated goes live, we examinean incident that happened with Apple’s iTunes. OnSeptember 30th, 2012 Apple released iTunes 10.7 andimmediately users started reporting activity on an ab-normal domain: bogusapple.com [11]. In essence, thenew version of iTunes began issuing queries to a do-main that was expected to never exist: bogusapple.com.Upon seeing this, one person registered that domain andbegan intercepting traffic, and capturing private infor-mation.

Another opportune example was raised at the Secu-rity and Stability Session of ICANN 46 [13]. In thetranscripts, and as provided in the audio, a partici-pant detailed their experiences of running the domaincorp.com. Among other things, this person explainedthat there was a sustained query load for DNS traffic. Atone point, this administrator began servicing email re-quests and was able to see undisclosed Securities and Ex-change Commission (SEC) filings for corporations beforethey were officially released. This serves as strong cau-tion against the assumption that simply counting queryrates is sufficient to measure all aspects of risk.

As an example of iTLD conflicts, [9] reported thatChrome can have difficulty identifying whether the en-tered text is a domain name or a search term. Prob-lems with an out of date suffix list led to issues wherecertain TLDs became difficult to access using Chrome.Additionally, [12] noted that the Safari browser was notimmune either. In addition, [4, 6] detailed issues withcookie scoping.

3.2 Risks

In order to estimate how much concern might be war-ranted, we propose a candidate measure to analyze howmuch risk each applied-for gTLD string represents toInternet users. To do this, we examine the following setof tangible threats that already exists, and we measuretheir prevalence on the Internet, today: i) Informationleakage and user tracking, ii) Denial of Service (DoS),

and iii) MitM attacks. This set of risks was chosen be-cause it covers a range of different concerns to Internetusers. While we strive to fully quantify our notion ofrisk, we acknowledge that this is just one candidate ap-proach to quantifying this general concept, and othersmay choose alternate approaches, or enhance the ap-proach we have taken with a more comprehensive set ofthreats considered. In order to measure these risks, weidentified specific attack vectors that adversaries coulduse to orchestrate each of these into actual attacks.

Information Leakage: One result of future delega-tions of new gTLD strings would be that the privateparties that will be servicing the new gTLD strings(Registry Operators, ROs) will be implicitly observ-ing (and potentially recording) information about DNSqueries. Currently, these queries go only to the RootServer Operators (RSOs). While this is still informa-tion leakage, the set of observers is poised to grow dra-matically (from the current 12 organizations to hun-dreds), and the restrictions on how the new ROs areallowed the use measurements are different than today’sRSOs. Moreover, once delegated, the registrants undernew gTLDs have the ability to register specific domainsfor targeted collisions. While there are more nuanceddifferences between the specific attacks that new ROsand registrants can launch, they are beyond the scopeof this writing. This form of information leakage canviolate privacy of users, provide a competitive advan-tage between business rivals, expose details of corpo-rate network infrastructures, or even be used to inferdetails about geographical locations of network assetsor users [37]. Another interesting note is that if enter-prises follow iTLD provisioning guidance (as discussedabove in Section 2), services with naming schemes,like: 〈service〉.〈location〉.foo-enterprise.corp ex-pose network and business structure to DNS operators.So, an organization that acquires the operation of thenew .corp gTLD could potentially use its collision withevery company’s .corp iTLD, and (in this example) beable to enumerate the numbers, types, and locations ofFoo-Enterprise’s internal structure. There is also evi-dence of similar issues in Novell configurations [8]. Be-yond monitoring NXDomain (or rcode 3) traffic, newROs might elect to take a more active role and beginproviding positive responses to queries.

Denial of Service: If a Registry Operator (RO) ora domain registrant within that gTLD elected to beginresponding to these queries with actual service identi-fiers (such as IP addresses), this could likely cause thequerier to attempt to establish a connection (such as toan IPv4 address, an IPv6 address, mail servers, etc.).Under these conditions, an operator could either DoSthe intended service by influencing attempts to resolve


3.2 Risks 3 GAUGING THE “RISK” LEVEL FOR NEW GTLD STRINGS

a resource’s name, or possibly launch a MitM attack andpotentially siphon information (such as user credentials,passwords, etc.) from sessions associated with the do-main name (by returning DNS responses that containinvalid mappings). This concern was recently expressedin a letter from PayPal to ICANN [18]. We note, thispredated the disclosure of issues with “Internal NamesCertificates” [43], which we discuss below and whichthemselves enable even more virulent and stealthy ver-sions of these attacks.

The DoS vector could be intentional, but also inad-vertent. If queries that are being issued for any of theseapplied-for gTLD strings are being serviced by regionalor otherwise non-global systems, then any active re-sponses from a newly delegated gTLD could interfere.One of the findings in Section 4 is that some applied-forgTLD strings have a statistically pronounced regionalbias. That is, some strings that are seeing query traf-fic today are heavily queried from specific regions, andthis could mean that delegation of those strings wouldhave acute regional effects (even if the global effect seemsmuted). For example, Estonia shows a very pronouncedaffinity for the applied-for gTLD string .zone. Even ser-vicing these requests from a new gTLD (instead of theNXDomain, or rcode 3, responses they currently elicitfrom the root) could disrupt the usage that they maycurrently have in their regions. However, the threat ex-ists that a RO could also begin answering them, causinga MitM attack.

Man in the Middle: Section 3.1 discusses specificexamples of non-existent domain names being registeredand then used to launch MitM attacks against domainnames that already exist, albeit at much smaller scalesthan a gTLD. While we believe that these existenceproofs actually illustrate a lower bound on the level ofconcern that is warranted, we leave this judgment tothe reader. One common defense against MitM attacksis to use Transport Layer Security (TLS) [29] becauseit uses end-to-end encryption to help protect sessionsfrom such attacks. Generally, TLS sessions rely on ex-ternal certificate verification schemes (like an internallist of “trusted” Certification Authorities) to bootstrapauthenticity of endpoints during start-up. However, theplanned introduction of the new gTLDs has opened evenTLS’ assurances up to attack as well. With new gTLDs,users may expect that any MitM would be unable tospoof connections, because when a user connects to aTLS service at a domain name, their expectation is thatthe certificate returned will be checked and its name(either the CommonName (CN) or Subject AlternativeName) will match that of the DNS domain name beingused for the connection. However a recent result (titled,“The Most Dangerous Code in the World: ValidatingSSL Certificates in Non-Browser Software”) has shownthat this verification step is often incorrectly performed

or even omitted [36]. One example, cited in Section 9 ofthis paper, is a code excerpt from PayPal’s online shop-ping cart that left users exposed to exactly this type ofvulnerability, when using PayPal services. However, theintroduction of new gTLDs may render these checks in-effective anyway, even when checked. A recent report byICANN’s SSAC detailed the dangers posed by “InternalName Certificates” [43]. This report advised that Cer-tification Authorities (CAs) have had a long-standingpractice of issuing certificates for domain names underiTLDs that are not currently delegated gTLDs. The im-plication of this is that anyone can obtain certificates fornames that correspond to new gTLD strings. These cer-tificates will have been issued by actual CAs, and passall TLS verification checks, and must be considered athreat not simply until they are revoked, but until theyexpire [15]. Thus, any TLS connection to any domainname under a new gTLD can be properly establishedusing a certificate that can be easily obtained by any-one.3

The dangers posed by this issue include the fact that itwould allow an adversary to register domains under newgTLDs and intercept existing traffic from unsuspectingusers. For example, if a company has provisioned theirpayroll system on a machine called foo,4 and placed itunder their .secure iTLD, then their internal networkwould most likely be rife with DNS queries for the namefoo.secure. However, these queries necessarily will beissued to the global DNS root zone before being ser-viced internally. Ironically, as a result, the operator offoo.secure will be ideally positioned to intercept thesequeries and use their Internet Name Certificate to createinsecure TLS (or even HTTPS) connections.

In addition to SAC057 [43], without the explicit scop-ing of authority codified by the rules published onPublicSuffix.org, any internal named certificate undera new gTLD could be applied to arbitrary subdomainsthroughout that entire branch of the DNS. That is, if acertificate for *.com were to somehow be minted (whichwould violate existing CA policies), and if it were pre-sented to a web browser, that browser would have amechanism (offered by PublicSuffix.org) to know to re-ject it and restrict the information leaks from cookiesharing between unaffiliated zones. This would not bethe case with *.secure, and without rules in Public-Suffix.org, such an Internal Name Certificate wouldhave security scope over all Second Level Domains un-der .secure.5 What is, perhaps, more troubling isthat Internal Name Certificates for well chosen SLDs(and wildcards below them) can certainly be issuedthroughout the hierarchy of applied for strings. So, for

3An example of this is illustrated in SAC057.4The label foo is just an example, but could just as easily be

payroll, Foo-Corp, sap, etc.5It is ironic that this could inherently reduce the innate security

of strings like .secure.


3.3 Threat Vectors 4 MEASUREMENTS

example, names like *.foo.secure, payroll.secure,www.secure, kerberos. tcp.secure, etc. can all berequested and issued. With well chosen seeds, a pre-emptive dictionary attack against .secure could scorchthe earth beneath the entire branch, and (perhaps iron-ically) render this new “Safe neighborhood,” uninhabit-able on day one. By contrast, as we discussed in Sec-tion 2, today’s DNS authority and delegation structureis loosely codified in a suffix list. While this list maybe prone to errors and staleness, it may also be viewedas providing some protection. For example, we cannotknow how quickly and accurately new gTLDs will be in-corporated into that list, or how fast their subzones willbe incorporated, or how well the delegation boundarieswill be represented, or how quickly end user softwarewill pick the new list up.

3.3 Threat Vectors

In order to understand some candidate vectors throughwhich risks might become active threats to users, we ex-amine a few specific instances of online behavior (whichare evident in measurements). There are multiple in-stances of tools and services that attempt to “help”users overcome connectivity problems through DNS-based discovery. For example, the Web Proxy Autodis-covery Protocol (WPAD) [34] is a technology that at-tempts to help users automatically discover if their net-work requires them to configure a Web proxy. Beforefetching its first page, a Web browser implementingthis method sends the local DHCP server a DHCPINFORM

query, and uses the URL from the WPAD option inthe server’s reply. If the DHCP server does not pro-vide the desired information, DNS is used. If, for ex-ample, the network name of the user’s computer ispc.department.branch.example.com, the browser willtry the following URLs in turn until it finds a proxy con-figuration file within the domain of the client:

http://wpad.department.branch.example.com/wpad.dat

http://wpad.branch.example.com/wpad.dat

http://wpad.example.com/wpad.dat

While not an Internet standard, we will show evidencein our measurements (in Section 4) that suggests it isindeed in wide use. The danger here is that, while thesequeries meet with NXDomain responses now, if a newgTLD operator (or a registrant operator under a newgTLD) were to start answering these queries with Webproxy information, then that operator could instruct anybrowser (or any type of WPAD client) to proxy all futureWWW traffic through the specified proxy.

In addition, the Intra-Site Automatic Tunnel Address-ing Protocol (ISATAP) [57] is an automatic transitiontunneling technique that discovers endpoints using DNSand may create IP tunnels based on what it finds. ISA-TAP is meant to transmit IPv6 packets between dual-stack nodes on top of an IPv4 network. The system

works by requiring system administrators to maintain aPotential Router List (PRLs) of IPv4 addresses repre-senting ISATAP interfaces of routers. This list is com-monly maintained as a FQDN and ISATAP typicallybuilds its PRLs via consulting the DNS and looking upDNS names like isatap.example.com. The danger inthis case is similar to the WPAD case: If a new gTLDoperator (or registrant operator) were to answer ISA-TAP queries with PRLs, then clients could begin tun-neling all of their traffic through the specified routers.

Finally, DNS-Based Service Discovery (DNS-SD) [25] attempts to locate services by using DNSqueries. DNS-SD is a protocol that enables net-work browsing and service discovery using onlystandard DNS packets and record types (RFC6763). DNS requests will take the FQDN form of〈Service〉. 〈Protocol〉. 〈DnsDomainName〉. Some

actual examples we observed include:kerberos. tcp.dc. msdcs.HNAH.ADROOT.HSBC.

ldap. tcp.SCAZTM01. sites.dc. msdcs.ent.wfb.bank.corp.

kerberos. tcp.dc. msdcs.sap.corp.

Of note, LDAP is Lightweight Directory Access Pro-tocol that enables distributed directory access servicessuch as “single sign-on” where one password for a useris shared across many services. Kerberos is a computernetwork authentication protocol. However, while thesetypes of services could be considered alarming, in thecontext of the new gTLDs, some queries are actuallyspecifically configured to query non-existent gTLDs.

Implicit in our discussion of these risks and threatvectors is a need to quantify them. For this, we nextexamine captures of data from several sources.

4 Measurements

Because our notion of risk includes threats that are be-yond just DNS queries and their responses, our measure-ments cover more than just DNS queries and responsesat the DNS root. We, necessarily, included measure-ments of the World Wide Web, X.509 certificates, andregional trends across all of these measurement modes.In this Section we discuss our measurement apparatuses,and then we broadly break our analysis down into twodimensions: Spread and Impact. The intuition behindthis is to illustrate how broadly measured effects areseen, and to what extent they appear to be having ef-fects.

4.1 Measurement Apparatuses

NXDomain (NXD) Analysis: For our NXDomain(or rcode 3) analysis we used a combination of data setsfrom historical Day in the Life (DITL) of the Internetcollections [24] and separate traffic captures from the a

and j DNS root servers which Verisign operates. The


4.2 Spread 4 MEASUREMENTS

locations of the root server instances of a and j are avail-able on the website http://www.root-servers.org/.Our NXDomain analysis allowed us to identify querypatterns, user behavior, and detect some degree of sys-temic trends. By contrast, our crawl of the Web (usingthe Internet Profile Service, IPS) allowed us to mea-sure some precursors to DNS queries, and provided ad-ditional evidence of X.509 certificate usage.

Internet Profile Service (IPS): The Verisign Inter-net Profile Service is a platform that is used primarilyinternally by Verisign to study the health of the overalldomain industry. This project crawls a small amount ofcontent from every domain that permits it to do so, andanalyzes request traffic from the DNS resolution process.The IPS corpus includes roughly 700 million Web pages.

The crawl process affords Verisign with the opportu-nity to build detailed statistics about linking relation-ships between domain names and the certificates thatthey have installed. The statistics from the resolutionprocess provide insight into which domains are mostheavily utilized on the resolution platform and some ofthe host names that are leveraged beneath the TLD reg-istries that Verisign operates.

SSL Observatory: In addition to the X.509 datagleaned from our IPS crawls, we cross-referenced cer-tificates found with SSL Observatory [31]. While thereare some obvious constraints in this data it does pro-vide a lower bound of related certificates for elementaryanalysis purposes.

4.2 Spread

In this study, we loosely define the term spread as rep-resenting how widely the effects of queries can be mea-sured. Specifically, the spread of the queries for applied-for gTLD strings can be used to quantify some aspects inwhich relatively few queries can (with sufficient spread)have large effects, and (alternately) spreading the ob-servation period of measurements out over time can en-hance their completeness. For the remainder of the text,when we discuss query measurements, if we do not ex-plicitly mention the source as DNS-OARC DITL data,we implicitly mean the source of measurement is fromthe a and j root servers.

Table 5 illustrates the relative percentages of the over-all traffic to the DNS root. One of the trends that thisdata illustrates is that, since at least as far back as 2006,the root system has seen queries for over 90% of thestrings that are now being considered for delegation asnew gTLDs. In addition, the overall trend is that thequery traffic for them is growing. Further, Figure 3 il-lustrates that one of the longitudinal trends over the lastseveral years is an increasing percentage of the applied-for strings have been seen in queries at the DNS root.

Indeed, the most recent DITL collection showed that98.30% of the currently applied-for strings were queriedfor within the DITL’s 48-hour collection period. Ad-ditionally, the lower curve in Figure 3 illustrates thepercent of the applied-for strings that were seen yearafter year, and we can see that in 2013, 96.95% of theapplied-for strings were re-observed from previous years.While the historical trend indicates that there has beena longstanding footprint of queries for the current set ofapplied-for strings, the measurements also suggest thatnot all applied-for strings are immediately visible in 48hours of query traffic to the DNS root, as provided inthe DITL data collection windows throughout this time-frame. Also note that only a single collection of theDITL data (2010) included participation from the fullset of root operators. All others were subsets of all rootoperators.

However, more protracted measurement periods yieldbroader coverage of the set of applied-for strings. Fig-ure 4 illustrates that almost 6 days of measurementswere required from both the a and j root servers be-fore all applied-for gTLD strings were observed. Thequeries for these strings were seen from 26,054 distinctAutonomous Systems (ASes). The relative popular-ity of each of the new gTLD strings (in NXDomaintraffic) is plotted as a histogram in Figure 5. ThisFigure illustrates the heavy-tailed distribution of thequery load for applied-for new gTLDs. Figure 6 de-picts a cumulative distribution function outlining thenumber of ASNs requesting an applied-for gTLD stringwithin this collection window. Figure 7 illustrates theapplied-for strings with the highest ASN diversity. AsRFC6762 suggested, .home (11,515 ASNs) and .corp

(8,555 ASNs) may in part be the result of private usageof multicast DNS, or general iTLD adoption and usein private networks. However, other measurements (be-low) suggest that some additional applied-for new gTLDstrings may have similar private usage patterns.

In order to begin gauging how richly used any givenapplied-for gTLD string might be, we investigated thenumber of unique Second Level Domains (SLDs) thatwe saw under each applied-for string. Figure 8 illus-trates that (by a large margin) .home has the richest di-versity of SLDs. Following this, the breakdown followsa heavy-tailed distribution with .cisco, .box, .corp,and .prod rounding out the top 5. One possible infer-ence to be drawn from this is that a greater diversity inthe namespace of the SLDs may be the result of muchmore nuanced (and possibly business critical) use by or-ganizations. However, we leave the judgment of this tothe reader, as it does not have a direct bearing on ourfindings. Figure 9 shows the distribution of how manyapplied-for new gTLD strings appear as links in pub-lic Web pages today. This measurement offers evidenceof one motivator that users may already be influencedby to direct queries and transactions to proposed new



When Valid NXDomains Applied-for gTLD Learning Applied-forQueries NXDomains Window gTLDs Seen

2006-01-10 60.08% 39.92% 3.70% 48.0hr 90.8%2007-01-09 67.28% 32.72% 2.55% 46.7hr 91.7%2008-03-18 72.45% 27.55% 4.80% 47.0hr 93.3%2009-03-30 72.00% 28.00% 5.52% 71.7hr 94.5%2010-04-13 72.13% 27.87% 4.62% 47.6hr 96.0%2011-04-12 65.15% 34.85% 5.22% 49.9hr 96.9%2012-04-17 59.97% 40.03% 7.24% 47.9hr 97.3%2013-05-28 56.98% 43.02% 8.99% 47.9hr 98.4%

Table 5: Relative percentages of root system traffic (among DITL participants), percent of all new gTLD stringsseen, and amount of time needed to converge on new gTLD set (“Learning Window”). This was measured usingDITL data. Note that the Applied-for gTLD NXDomains column represents the percentage of NXDomain traffic.

0

10

20

30

40

50

60

70

80

90

100

2007 2008 2009 2010 2011 2012 2013 2014

Perc

ent o

f All

Appl

ied-

For S

tring

s

Number of Applied-For Strings Seen in DITL Data

Observed Applied-For StringsRe-Observed Strings

Figure 3: This Figure illustrates the percent of applied-for gTLD strings that were seen in DITL collections,year after year. In addition, the lower curve shows what percent of the seen strings were seen in previous years(suggesting more consistent query patterns for strings). Note that this plot begins in 2007 as the 2006 DITL data,while at 90.8% itself, was used for the initial learning set.



Figure 4: This Figure shows the CDF of the learning rate of new gTLD strings for just the a and j root instances.It shows that it takes just over 5 days to observe all of the new gTLD strings in NXDomain traffic.

0.1

1

10

100

.home.corp

.ice.prod

.ads.global

.cisco.inc

.host.hsbc

.mail.dev

.network

.site.group

.box.office

.smart

.ltd .msd.google

.star.win

.data.sap

Top 25 New gTLD Traffic Percentages

1e-06 1e-05

0.0001 0.001

0.01 0.1

1 10

100

0 200 400

600 800

1000 1200

1400

All New gTLD Traffic Percentages

Figure 5: This Figure shows the percentages of all NXDomain traffic that was seen for each of the applied-forgTLD strings (note the logscale).



Figure 6: This Figure is a CDF of the number of ASNs that issued queries for each applied-for gTLD string.



Figure 7: This Figure shows the applied-for gTLD strings with the highest ASN diversity.

gTLDs. One possible reason for these links could be theintention for the enclosing Web page to direct browsersto internal sites, another likely explanation for some ofthem is that they represent typos or information thatwas not updated when the Web property was movedinto a production environment. In any case, these linkscan be responsible for user traffic, and expose an elementof risk.

While the logical converse to wide-spread usage ismore narrow usage patterns, this doesn’t necessarilymean this type of usage is less important or less critical.Perhaps the opposite is true, in some circumstances. Wenext consider queries for applied-for new gTLDs thatexhibit strong regional preferences, and query sourcesthat exhibit marked periodicity (i.e., query for applied-for new gTLDs at an abnormally regular interval). Theintuition behind these investigations is that new gTLDsthat may not be as globally popular as some withbroader appeal might actually be very important to cer-tain smaller countries (or regions) and consumers. Ourbelief is that name conflicts for those applied-for gTLDscould have acute impacts on entire regions, withoutseeming to be as pronounced of a concern in the globalquery context (i.e., “weak signals”).

Regional Preferences: In searching for regionalaffinities, we develop a candidate metric to determinewhich regions show disproportionate levels of interest in

any of the applied-for gTLD strings. Our metric is justone candidate quantification of this sort of behavior, andothers may choose different approaches or enhance ourapproach. Regardless, our metric offers a concise quan-tification of this general behavior.

In order to determine if one country (or region) has apronounced affinity for a given applied-for gTLD string,we begin by mapping query sources to the “region”that they come from, according to ISO 3166 RegionCodes [32]. We then establish a baseline affinity foreach gTLD for each region across all of the gTLDs thatit queries. That is, we determine what each region’s“normal” query patterns are for each applied-for gTLDstring. Then, we determine if one region has a distinctlydifferent level of interest in any string.

To establish our per-gTLD baseline level of interestfor a region (igTLD

r ), we first calculate the total numberof queries that each region r issues for all new gTLDsQr. Table 6 shows some example query counts for somegTLDs, broken out per region. Next, we divide thequery count for each new gTLD in region r by the totalof all queries seen:

igTLDr =

qgTLDr

Qr

Where qgTLDr is the count of queries seen for a given

gTLD from a specific region r, and igTLDr represents the

relative query fraction seen for a specific gTLD in region



1000

10000

100000

1e+06

1e+07

1e+08

HOMECISCO

BOXCORP

PRODSITE

SFROFFICE

BLOGWOW

GOLDDEV

WEBSMART

IINETTAOBAO

CASASAMSUNG

ZIP GOOGLE

NETWORK

INCSCHOOL

MAILWORLD

Top 25 Unique Second Level Domains (SLDs) Under gTLDs

0.1 1

10 100

1000 10000

100000 1e+06 1e+07 1e+08

0 200 400

600 800

1000 1200

1400

All Unique Second Level Domains (SLDs) Under gTLDs

Figure 8: This Figure illustrates (in logscale) the diversity of SLDs under each of the applied-for new gTLDstrings. The large plot shows the top 25 applied-for gTLDs, and the smaller plot shows the entire distribution ofapplied-for strings.



0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

website

google

yahoodev

hotmail

linkgmail

youtube

newsblog

homeamazon

shopcontact

webskin

search

aolmail

sitewebs

pagehere

mediaaaa

Top 25 HTML Links Found for Each New gTLD

0.1

1

10

100

1000

10000

1 10 100 1000

All HTML Links Found for Each New gTLD (Logscale)

Figure 9: This Figure illustrates the relative counts of new gTLD strings seen in Web pages observed via theIPS Web crawl. The larger Figure illustrates the distribution of the number links (seen in all pages) to the 25applied-for gTLDs with the greatest link counts, and the smaller (logscale) figure describes the distribution acrossall applied-for new gTLDs.



gTLD US CA GB DO FR

.home 14.67M 18.50M 3.05M 3.03M 0.22M

.corp 13.76M 0.39M 0.11M 0.03M 0.79M

.ice 4.08M 0.00M 0.00M 0.00M 0.00M

.prod 1.04M 0.01M 0.00M 0.00M 0.33M

Table 6: This Table shows sample query counts (in unitsof millions of queries), broken out per region.

gTLD US CA GB DO FR

.home 0.32 0.95 0.92 0.98 0.10

.corp 0.30 0.2 0.3 0.1 0.37

.ice 0.9 0.0 0.0 0.0 0.0

.prod 0.2 0.0 0.0 0.0 0.16

Table 7: This Table shows sample query counts, as anormalized fraction of all received NXDomain queries,broken out per region.

r. Table 7 illustrates how this normalizes the query ratesseen from each region, for each applied-for gTLD.

In calculating the relative fraction of queries sent byeach region (and to each applied-for gTLD) we can seedifferences in query affinities. Our general observationis that for most applied-for gTLDs, across regions, theresults are somewhat consistent (regions tend to mirroreach others’ affinities), and deviations (like in Table 6)help to quantify when a region has an abnormal affinityfor an applied-for gTLD. We quantify a regional affinityas any regional interest (igTLD

r ) that is more than twostandard deviations (2×σgTLD) away from the averageinterest across all regions IgTLD. That is, we define anapplied-for gTLD’s overall interest IgTLD as the averageof all regional interests for that gTLD:

IgTLD =

∑|R|i=1 i

gTLDi

|R|

Where R is the set of all regions. Others may chooseto define regional affinity with a different constant fac-tor (other than 2), and we just present this choice as areasonable starting point.

The results of this approach lend a continuous met-ric of which regions may have abnormally high pref-erences for applied-for gTLDs (in general), and whichgTLDs have heavy regional affinities. For exam-ple, Japan displays high affinity scores for .tokyo

(12.06 × σ.tokyo), .osaka (9.42 × σ.osaka), and .kyoto

(7.88 × σ.kyoto); whereas the Netherlands has a highaffinity for .amsterdam (8.75 × σ.amsterdam). Simi-larly major brands appear to have higher affinities fortheir brand-applied-for gTLDs in their target markets:US:.comcast (3.55 × σ.comcast), Brazil:.uol (4.94 ×σ.uol), CN:.baidu (11.06 × σ.baidu), DE: .lanxess

(4.98×σ.lanxess), or in France, .sfr has an affinity scoreof 13.6× σ.sfr.

Some of the more pronounced affinities include:.exchange, which has an affinity score of 13.90 ×σ.exchange in Estonia. This seems noteworthy due tothe possibility that a future collision with the .exchangegTLD could affect email deliverability if query hits cor-respond to Microsoft Exchange deployments. Also inter-esting is the disproportionate affinity scores of 13.77 ×σ.love and 12.95 × σ.accountant, both from the U.S. Vir-gin Islands. Also, .search, which draws a high affinityof 14.21 × σ.search score from South Korea. In Aus-tralia both .win and .iinet receive high levels of affin-ity, at 14.33×σ.win and 12.82×σ.iinet, respectively. Sev-eral regions have high affinity scores for .school (Aus-tralia, New Zealand) while in Germany, India, Belgiumthey exhibit higher localized affinities for alternativesor translations (.schule, .training, and .college).Though interpreting the relative significance of thesescores is somewhat qualitative, the metric helps isolateleading indicators for us to examine weak signals. Thatis, if query rate were the lone metric, one might have ex-cluded .accountant, even though it displays some highaffinity traffic from the U.S. Virgin Islands because it isin the bottom half of traffic counts. Additionally, onemight exclude .tjx because it is ranked 908 in overalltraffic ranking, but it has an affinity score of 10.41×σ.tjx

in Haiti. To illustrate some of the trends, Table 8 lists asnapshot of several of the regions in each continent (bar-ring Antarctica) that show some of the highest regionalaffinities.

Periodicity: In addition to our candidate measure-ment of regional affinities, we also evaluate the possi-bility that applied-for new gTLD strings are already inuse by automated systems, whose traffic may displaymeasurable periodicity. That is, we speculate that somesystems (such as, monitoring systems or embedded de-vices) may periodically beacon out DNS queries. So, wemeasured the inter-query time gap for each query to eachapplied-for gTLD from each AS, and then calculated thevariance for each time series. Our intuition is that whenqueries are emitted at roughly the same rate over time,the variance in this value should be low. Under high con-currency, one might expect low variance scores (as queryrates would approach the inverse of the TTL period:λ = 1

TTL ). Under lower concurrency, our hypothesis isthat similarly low variance scores might suggest some de-gree of weak signal (perhaps automation). What we findfrom measurements is that some of applied-for gTLDsstrings with the greatest query volume (such as .corp)do indeed have very low variance scores from large ASes(such as Verizon, Rackspace, Deutsche Telekom, etc.).Our interpretation of this metric is that it offers an ad-ditional piece of evidence that some ASes may have areliance on applied-for gTLD strings.



Region / gTLD σgTLD

Europe (EU).page 12.65.hot 10.83.office 8.78.epson 8.17Macedonia (MK).dance 11.40.room 9.45.promo 8.52.are 8.50United States (US).host 3.62.comcast 3.55.ice 3.50Haiti (HT).thd 11.70.ril 11.45.how 11.17.church 10.78Myanmar (MM).vip 12.97.kia 12.82.university 12.32Japan (JP).bbt 13.15.bet 12.66.email 10.82Angola (AO).software 12.00.security 8.62.shop 8.36.bcg 8.11Nigeria (NG).store 12.45.pharmacy 11.49.bible 10.07.pictures 9.90.mobile 9.84Venezuela (VE).ford 13.62.barcelona 13.22.gree 8.83.movistar 8.76Paraguay (PY).click 10.83.free 8.73.frontier 6.95.navy 6.59Australia (AU).win 14.33.iinet 12.82

Table 8: This Table describes the regional affinities cal-culated from our methodology.

In addition, however, a more intricate set of interac-tions illustrates how complicated some of the effects ofDNS resolution can be. A particularly poignant caseemerges for a specific string under the .box applied-forgTLD: fritz.box. This domain name appears to beused by a specific brand of Small Office / Home Office(SOHO) servers called FRITZ!Box [33], which imple-ment the Session Initiation Protocol (SIP) [56], and arepopular in Europe. As a Voice over IP (VoIP) protocol,a bad interaction between SIP and DNS resolution couldnot only lead to telephony outages for subscribers butcould also (in at least one particular case, discussed be-low) prompt crashes in VirtualBox [59] (a popular brandof virtual machine). Below the fritz.box domain, a di-verse set of third and fourth level labels can be observedto range from strings with no obvious meaning (such askmswiyfxcj), to DNS service discovery ( dns-sd. udp),to more common strings (like twitter); but with mea-surably low variance in inter-query periodicity. Exami-nation of these labels should raise concern when inter-secting them with the general roles of home SIP servers.

One implication of the combination of DNS resolu-tion failure and SIP calls from home users is that fail-ure modes could disrupt subscribers’ abilities to makeemergency phone calls. This sort of failure could bebrought about because SIP calls require DNS servicediscoveries for control messages to initiate calls. How-ever, when DNS resolution is affected, even more gen-eral failures could be caused behind SOHO routers. Ina ticket listed in the the bug tracking system for Ora-cle’s VirtualBox [58], an interaction between several ver-sions of FRITZ!Boxes, VirtualBox, and DNS led to ker-nel panics in virtual machines. The bug ticket includesthe following capture of the default DNS configuration(resolv.conf) for FRITZ!Boxes:

...

#

# This file is automatically generated.

#

domain fritz.box

nameserver 192.168.20.1

From this default configuration we can see thatFRITZ!Boxes are configured to use .box as an iTLD.The ticket [58] goes on to identify that a workaround forthe kernel panic is to use Google’s public DNS resolu-tion (8.8.8.8), and this correlates well with our measure-ments. We observe that Google’s ASN has measurablylow variance in its periodicity for .box. Further inves-tigation into FRITZ!Box reveals that its configurationpages are all internally serviced from fritz.box, andtheir configuration advice [22] notes that loading thispage can both be problematic, and can cause browsersto incrementally send DNS queries as the user enterseach part of a DNS domain name. Figure 10 illustratesthe most popular SLDs under the .box string.



Figure 10: This Figure shows popular SLDs within .box. The label .fritz is the most frequent, but the threatvector for .isatap is also visible.


4.3 Impact 5 SECURITY ANALYSIS: HOW PERVASIVE IS THE RISK?

Another interesting example is .sfr, which we iden-tified a regional affinity for with France (above). Thisstring also has a measurably low variance score froman AS registered to the Societe Francaise du Radiotele-phone S.A. These two pieces of evidence reinforce eachother and may suggest that this string is already ac-tively relied upon. Other periodic trends include .ice

from Microsoft, or .maif from British Telecommunica-tions. Each of these applied-for gTLD strings have vary-ing traffic patterns across their constituent ASes, butthis metric helps identify which ASes may be more sys-tematically dependent.

4.3 Impact

We, next, use measurements of specific network proto-cols (WPAD, ISATAP, and DNS-SD queries) to estimatethe impact, or degree to which Internet users may bevulnerable to subversion by the new gTLDs.

WPAD: Measurements of the WPAD label showedthat 1,002 of the applied-for gTLD strings received re-quests of the form wpad.〈*〉.〈gTLD〉. Based on HTMLlinks observed in our IPS system, we have evidence thatexisting Web pages are at least one source of query traf-fic that drives user agents (such as Web browsers, someof which implement WPAD) to new gTLDs. Figure 11shows the most requested WPAD gTLDs by distinctASNs.

As previously stated, .corp has been noted in sev-eral publications to be associated with private use. Fur-ther inspecting the WPAD NXDomain traffic for .corpshowed numerous major corporations present within thequeries. Figure 12 shows the most popular SLDs for.corp with a WPAD label also present in the FQDN.This Figure suggests that numerous corporations maybe using some form of internal TLD namespace un-der the iTLD .corp. Note the incidence of SLDs like“AirBus,” which could indicate a dependency on NXDo-mains by a large aerospace manufacturer. Or, consider“AD,” which has been used by some as an Active Direc-tory control point [7]. Furthermore, our measurementsshow evidence that (due to the nature of WPAD’s res-olution look up behavior) if a registry operator were tobegin responding to queries for wpad.corp, many busi-nesses would be directly vulnerable to risks such as thoseidentified earlier. These risks are similar to those ex-posed by the actual incidents discussed in Section 3.1.

Perhaps, more alarming are the implications thatcould be drawn from the most popular SLDs under.cisco, seen in Figure 13. Here we can see that notonly is wpad the second most popular SLD, but isatapis number one. Moreover, DNS-SD-like labels (. udp

and . tcp) round out the top seven, and other currentgTLDs (such as .gov, .net, and .info) are in the list.Further, there are strings like .user-pc, .server, and

.owner-pc (just to name a few) that may suggest DNSqueries for internally-scoped names are leaking out tothe global DNS root. This could, perhaps, enable a ven-dor to learn about internal network structures of theclients they sell to, if (in the future) .cisco were to beoperated by such an entity.

ISATAP: Measurements of the ISATAP label showedthat 951 of the unique applied-for gTLD strings receivedrequests of the form isatap.〈*〉.〈gTLD〉. Figure 14shows the most requested ISATAP gTLDs by distinctASNs. This data shows that applied-for gTLD stringsare being widely used in private networks.

DNS-SD: Measurements of the DNS-SD like FQDNsshowed that 1,036 of the applied-for gTLD stringsreceived requests of the form UDP.〈*〉.〈gTLD〉 orTCP.〈*〉.〈gTLD〉. Figure 15 shows the most requested

DNS-SD applied-for gTLDs by distinct ASNs.

5 Security Analysis: How Perva-sive is the Risk?

The goal of our security analysis is not to precisely quan-tify the degree to which any given string, region, AS,user, etc. is at risk for compromise or attack. Rather,we use our measurements as evidence of potential risks,and extrapolate the relative weights of the risk posedby each applied for gTLD, based solely on our mea-surements. We submit that our security analysis servessimply as quantitative evidence that certain risks doexist (without representing their conclusive acuteness).To this end, our Risk Matrix (Table 9) illustrates ourmeasured risk vectors, and it is sorted according to theamount of evidence that we measured.

In this table, our three risk vectors for setting upproxied, tunneled, or other services are described in thecolumns for WPAD, ISATAP, and DNS-SD. The valuesin this table represent the number of unique ASes thatwere observed emitting queries for various applied-fornew gTLD strings that might be exploited either inten-tionally by an adversary, or inadvertently. In addition,we list the relative fraction of all ASes that were seenquerying for this applied-for new gTLD string versus thenumber of ASes that queried this string for these ser-vices, in order to represent the spread of the risk acrossconstituent queriers.

In addition to this, we measure how many visibleX.509 certificates exist in public crawls for these strings.We note that while we feel this measurement is valuable,SAC057 [43] illustrates that anyone can acquire a legiti-mate X.509 “Internal Name Certificate” from authenticCAs at any time. Therefore, concern is warranted, evenin the absence of any observed internal named certifi-


5 SECURITY ANALYSIS: HOW PERVASIVE IS THE RISK?

Figure 11: This Figure shows the top gTLD strings seen to have WPAD queries issued for them. Of note is that.home, .corp, and .cisco round out the top three SLDs, respectively.

Figure 12: This Figure shows popular SLDs within .corp.



Figure 13: This Figure shows popular SLDs within .cisco. The labels .isatap, .wpad, and . udp and . tcp

could directly indicate threat vectors, but are certainly not the only SLDs that could be problematic.



Figure 14: This Figure shows the most popular applied-for gTLDs for which ISATAP queries were seen.

Figure 15: This Figure shows the most requested DNS-SD gTLDs by distinct ASNs.



gTLD WPAD ISATAP DNS-SD X.509 HTML # Risk ASN Regional InterisleASNs ASNs ASNs Certs Refs Vectors Spread Affinities Risk

MEDICAL 83 59 202 1 12 6 0.71 JP: 7.84 UncalculatedPR: 10.50

CORP 3744 2984 5020 378 130 6 0.65 AP: 4.34 HighGT: 2.33HN: 4.24HR: 3.47HU: 3.42LV: 2.01NI: 2.89

BOX 631 1588 702 53 36 6 0.65 MQ: 12.27 UncalculatedNA: 7.08

HOTEL 112 233 128 1 39 6 0.61 RW: 3.15 UncalculatedUZ: 13.42

NETWORK 679 1026 778 39 28 6 0.61 DK: 2.98 UncalculatedFI: 13.80

GROUP 653 565 925 22 27 6 0.60 RW: 3.89 UncalculatedTG: 12.56

GLOBAL 912 742 1305 21 18 6 0.60 AT: 3.15 UncalculatedFI: 2.04GT: 5.63KR: 6.06MN: 2.79SE: 7.73SK: 2.36

ADS 782 614 1199 79 43 6 0.57 FR: 6.05 UncalculatedRE: 11.71

HOUSE 169 175 150 3 49 6 0.56 BN: 6.71 UncalculatedPR: 8.55PY: 3.93UY: 2.24

OFFICE 648 610 884 659 33 6 0.55 EU: 8.78 UncalculatedGP: 3.20HU: 3.34MK: 3.30PR: 3.62UA: 2.39UZ: 4.23

OLYMPUS 131 94 127 3 2 6 0.53 AT: 2.19 UncalculatedCU: 9.68SK: 3.74

SCHOOL 156 192 232 2 39 6 0.53 AE: 3.83 UncalculatedAU: 3.06MV: 9.96NZ: 3.05TW: 5.34

GMBH 26 21 62 7 2 6 0.52 AT: 3.27 UncalculatedDE: 8.40HR: 2.90

DENTAL 42 34 37 2 5 6 0.51 AT: 9.95 UncalculatedLLC 214 174 213 2 11 6 0.50 MN: 14.21 UncalculatedSOLUTIONS 31 29 41 2 36 6 0.48 LV: 10.79 UncalculatedCLINIC 35 33 43 1 4 6 0.47 CY: 11.90 UncalculatedMOSCOW 18 34 21 2 3 6 0.46 AE: 6.01 Uncalculated

CY: 4.93HSBC 274 68 409 9 7 6 0.46 GT: 5.59 Uncalculated

HN: 12.30SV: 2.28

SECURITY 38 27 41 1 14 6 0.17 AO: 8.62 UncalculatedLT: 4.64MM: 5.20

SECURE 47 64 59 1 65 6 0.09 LV: 2.74 UncalculatedSK: 11.44

Table 9: This is a snapshot of the overall Risk Matrix, calculated by measuring all of risk vectors


7 CONCLUSION

cates for new gTLD strings. Nonetheless, we includemeasured evidence as a potential increased level of riskin our matrix as it may (if nothing else) indicate thatattention has already been paid to a string and X.509certificates already exist that could enable an adversaryor facilitate an attack.

Our Risk Matrix also includes our measurement ofthe incidence of applied-for gTLD strings seen in HTMLpages. As we discussed in Section 4.3, we consider thepresence of these links as one possible risk vector. Whilemany could be misconfigurations, some could also belinks that are only intended to resolve within a corpo-ration or development environment. Regardless of howthey came to be in public pages, their presence can driveuser traffic to strings that are (as yet) not delegated.The change in delegation status of the relative HTMLlinks will impact the experience and underlying systemsbehavior for users, and we consider that a risk.

Finally, we considered regional affinities as an inde-pendent measure of risk (as we described earlier). Thismeasurement is also described in our Risk Matrix.

While our analysis of this matrix is not a quanti-fied metric of danger, we have sorted the overall re-sults based on the number of our risk factors that eachapplied-for new gTLD string triggered, and the relativespread observed. Table 9 enumerates just those newgTLD strings that appeared to have the most measur-able evidence of potential risks, under one candidatesorting scheme. This subset of risks is sorted basedon how many risk vectors were observed for each newgTLD string (WPAD, ISATAP, DNS-SD, X.509 Inter-nal Named Certs, etc.), and then how widely spreadacross the querying ASes those risks were observed (ona per-string basis). Our matrix contains other strings(which are much lower down in the list) that illustratehow intuitively more nuanced and less popular stringsexhibit lower probabilities of collisions in the namespacethan sexier and more common strings, such as .secure.

6 Discussion

Our goal with this study is to illustrate evidence ofpotential issues that may arise with the delegation ofthe applied-for new gTLDs (and new TLDs in general).Beyond this, it is our belief that constructive recom-mendations can be issued and followed to help miti-gate problems that may lie ahead, and we enumeratea candidate list here. At a high level, we simply recom-mend that ICANN implement those recommendationsthat were outlined in the “Signposts in Cyberspace” re-port [48], “Scaling the Root” study [19], SAC045 [40],SAC046 [41], SAC057 [43], and SAC059 [42]. These areall work products which we have, in various capacities,participated directly in over the past decade. At a highlevel, these recommendations are:

1. Build a root server system instrumentation capa-bility to accurately assess the systemic impact ofapplied-for strings, as well as to detect stresses onthe root server system itself.

2. Develop technical and policy frameworks for brak-ing and rollback of delegations, perhaps to includeephemeral delegations but only after recommenda-tions above are effectuated.

3. As per above, assess potential user impact and no-tify potentially impacted parties of impending del-egation, and provide mitigation recommendationsto Internet users and operators that could be im-pacted.

4. Establish a communications plan to notify poten-tially impacted parties, vendors, and establish op-erations of, and build, a call center and supportingframework that outlines whom to contact if issuesarise.

5. Evaluate liabilities and risks associated if issuesarise, and what protections are in place for involvedparties.

In addition, if they haven’t done so already, we be-lieve the ICANN Governmental Advisory Committee(GAC) and other such ICANN stakeholders may wantto consider engaging with their respective agencies toexplicitly address the question of if (and which) stringsmay be in use in their critical infrastructure and keyresources (CIKR) [28, 14]. This would enable them toforewarn impacted parties, as well as potentially miti-gate impacts prior to delegation of a given string. Thisis particularly vital given their context related to DNSecosystem, and their proximity to the new gTLD pro-gram over the past several years. This is also importantfor the obvious reason that simply removing a delegatedstring (un-delegating) could possibly be an entirely in-adequate remedy for damages that could result; for in-stance caching and various systemic effects could resultin prolonging any impacts in addition to other residualeffects.

7 Conclusion

In this study, we conduct one of the largest investiga-tions of DNS root zone traffic to date, with DNS queriesfrom up to 11 of the 13 root instances, dating back to2006. In addition, we propose a novel methodology togauge the risk posed by applied-for new gTLD strings,and quantify it using measurements of DNS, the WorldWide Web, X.509 certificates, regional preferences, andinter-query timing analysis.

What we found was that quantifying the risk thatapplied-for new gTLDs pose to Internet users goes be-


REFERENCES REFERENCES

yond simply evaluating query rates for, as yet, undele-gated new gTLD strings. Indeed, we found several in-stances where automatic proxy protocols, X.509 internalnames certificates, and regional traffic biases could leavelarge populations of Internet users vulnerable to DoSand MitM attacks, immediately upon the delegation ofnew gTLDs.

Our measurements and quantification of risks exist asjust candidate approaches. While we feel there is quan-tifiable evidence of risk, there is clearly room for alter-nate methodologies and this effort will certainly benefitfrom community input and more comprehensive analy-sis. However, we believe that this study constitutes thefirst attempt to conduct an interdisciplinary (and con-sumer impact) analysis of the new gTLDs in the globalDNS.

One of the tangible benefits of this study has beenquantitative analysis that has qualified some of the im-plications of unresolved recommendations. In this work,we have presented evidence that suggests that theseunresolved recommendations have potentially damag-ing implications to general Internet consumers, corpo-rations, and public interest. Additionally, we believethat the new gTLD program could pose very real risksto both the set of entities that have been charged witheffectuating new gTLD delegations, and the set of thoseresponsible for giving due consideration to (and imple-mentation of) recommendations provided by ICANN’sadvisory committees and expert contributors, if thoserecommendations remain unresolved.

While in a 2005 National Research Council [48] studythe number of recommended delegations was on the or-der of tens per year, we are not advocating any partic-ular number. We are, however, advocating that instru-mentation be in place and recommendations be enactedto support the safe introduction of new gTLDs.

We believe that further study and express focus onimplementation of recommendations already provided iscritical in progressing the new gTLD program in a safeand secure manner for all stakeholders. We believe thatthis work has demonstrated evidence that risks exist, toboth the existing Internet user base, as well as to newgTLD applicants and services consumers. We believerecognition of this evidence and explicit consideration,planning, and appropriate resourcing for further studyand resolution of outstanding recommendations is themost prudent and expeditious manner with which tomove forward.

References

[1] DNS Namespace Planning. Support 254680,Microsoft. http://support.microsoft.com/kb/

254680.

[2] Internet Corporation for Assigned Names andNumbers (ICANN). http://www.icann.org/.

[3] Naming conventions in Active Directory for com-puters, domains, sites, and OUs. Support 909264,Microsoft. http://support.microsoft.com/kb/

909264.

[4] Public Suffix List. In Mozilla Wiki. https://wiki.mozilla.org/Gecko:Effective_TLD_List.

[5] Novell Open Enterprise Server. Novell dns/dhcpservices administration guide, Novel, October2006. https://www.novell.com/documentation/

oes/pdfdoc/dhcp_enu/dhcp_enu.pdf.

[6] Bug 252342 - fix cookie domain checks to notallow .co.uk . In Bugzilla@Mozilla , April2008. https://bugzilla.mozilla.org/show_

bug.cgi?id=252342.

[7] MAD dns naming ? In Novell Forums, July2008. http://forums.novell.com/novell/

novell-product-discussion-forums/netware/

nw-other/dns-dhcp/336488-mad-dns-naming.

html?pagenumber=%3E.

[8] Diagnosing a 6038 Error in Identity Man-ager. Support, Novel, January 2010. https:

//www.novell.com/communities/node/9465/

diagnosing-6038-error-identity-manager%3E.

[9] Google Chrome handles new TLDsbadly. In Domain Incite Blog, May2012. http://domainincite.com/

8978-google-chrome-handles-new-tlds-badly.

[10] New Generic Top Level Domains Applicant Guide-book. In ICANN, June 2012. http://newgtlds.

icann.org/EN/APPLICANTS/AGB.

[11] Why does iTunes 10.7 try to contact the domainbogusapple.com? In Apple SUpport Communities,October 2012. https://discussions.apple.com/thread/4380270?tstart=0.

[12] Apple, Google and Microsoft still don’t understandnew TLDs. In Domain Incite Blog, January 2013.http://domainincite.com/11673-apple-google-and-microsoft-still-dont-understand-new-tlds.

[13] BEIJING - New gTLD Security Stability &Resiliency (SSR) Update. In ICANN 46, April2013. http://beijing46.icann.org/bitcache/

c1f445deb97b93056b6d528bc82ad405b2a26212?

vid=50079&disposition=attachment&op=

download.



[14] E9-1-1 best practices, final report. InCSRIC III: WORKING GROUP - 8, March2013. http://transition.fcc.gov/bureaus/

pshs/advisory/csric3/CSRICIII_6-6-12_

WG8-Final-Report_Pt2.pdf.

[15] How certificate revocation (doesn’t) work inpractice. Blog post, Netcraft, May 2013.http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html.

[16] New gTLD Security and Stability Considera-tions. Technical Report 1130007 version 2.1,2013. http://www.verisigninc.com/assets/

gtld-ssr-v2.1-final.pdf.

[17] Part 2 of 5; Internet Infrastructure: Stabilityat the Core, Innovation at the Edge. In Be-tween the Dots Blog of Verisign, May 2013.http://blogs.verisigninc.com/blog/entry/

internet_infrastructure_stability_at_the.

[18] Proposed Delegation of Invalid Namesfrom SAC 045 and RFC 6762. Corre-spondence, Paypal, March 2013. http:

//www.icann.org/en/news/correspondence/

hill-smith-to-chehade-crocker-15mar13-en.

[19] Jaap Akkerhuis, Lyman Chapin, Patrik Flt-strm, Glenn Kowack, Lars-Johan Liman, andBill Manning. Scaling the Root: Reporton the Impact on the DNS Root Systemof Increasing the Size and Volatility of theRoot Zone. Technical report, September2009. http://www.icann.org/en/groups/rssac/

root-scaling-study-report-31aug09-en.pdf.

[20] R. Arends, R. Austein, M. Larson, D. Massey, andS. Rose. DNS Security Introduction and Require-ment. RFC 4033, March 2005.

[21] artemis group. .secure a safer Internet. https:

//artemis.net/ncc-group.

[22] AVM Knowledge Base. FRITZ!Box user interfacecannot be opened. http://service.avm.de/

support/en/SKB/FRITZ-Box-7390-int/649:

FRITZ-Box-user-interface-cannot-be-opened.

[23] Nevil Brownlee, KC Claffy, and Evi Nemeth. Dnsmeasurements at a root server. In Global Telecom-munications Conference, 2001. GLOBECOM’01.IEEE, volume 3, pages 1672–1676. IEEE, 2001.

[24] CAIDA and DNS-OARC. A Day in the Life ofthe Internet (DITL) . http://www.caida.org/

projects/ditl/.

[25] S. Cheshire and M. Krochmal. DNS-Based ServiceDiscovery. RFC 6763, February 2013.

[26] S. Cheshire and M. Krochmal. Multicast DNS.RFC 6762, February 2013.

[27] S. Cheshire and M. Krochmal. Special-Use DomainNames. RFC 6761, February 2013.

[28] The President’s National Security Telecommu-nications Advisory Committee. Nstac report tothe president on communications resiliency. April2011. http://www.ncs.gov/nstac/reports/

NSTAC%20Report%20to%20the%20President%

20on%20Communications%20Resiliency%

20(2011-04-19)(Final)(pdf).pdf.

[29] T. Dierks and E. Rescorla. The transport layersecurity (tls) protocol version 1.2. RFC 5246, 2008.

[30] D. Eastlake and A. Panitz. Reserved Top LevelDNS Names. RFC 2606, June 1999.

[31] Peter Eckersley and Jesse Burns. An observatoryfor the ssliverse. In Defcon 18, 2010.

[32] International Organization for Standardization.ISO 3166-1:2006 Codes for the representation ofnames of countries and their subdivisions - Part 1:Country codes. ISO, Geneva, 2 edition, 2006.

[33] FRITZ!Box. AVM - Everything’s Networked WithFRITZ! http://www.fritzbox.eu/en/index.

php.

[34] Paul Gauthier, Josh Cohen, Martin Dunsmuir, andCharles Perkins. Web Proxy Auto-Discovery Pro-tocol draft-ietf-wrec-wpad. Internet draft, IETF,December 1999. http://tools.ietf.org/html/

draft-ietf-wrec-wpad-01.

[35] E. Gavron. A Security Problem and Proposed Cor-rection With Widely Deployed DNS Software. RFC1535, October 1993.

[36] Martin Georgiev, Subodh Iyengar, SumanJana, Rishita Anubhai, Dan Boneh, and Vi-taly Shmatikov. The most dangerous code in theworld: validating ssl certificates in non-browsersoftware. In ACM Conference on Computer andCommunications Security, pages 38–49, 2012.

[37] Saikat Guha and Paul Francis. Identity Trail:Covert Surveillance Using DNS. In Proceedings ofthe 7th International Symposium on Privacy En-hancing Technologies (PETS), Ottawa, Canada,Jun 2007.

[38] Vernita D. Harris. Addition of New gTLDs to theRoot Zone. http://www.icann.org/en/news/

correspondence/harris-to-kane-02aug13-en.

pdf.



[39] Kelly Jackson Higgins. New .secure InternetDomain On Tap. In Dark Reading, May 2012.http://www.darkreading.com/management/

new-secure-internet-domain-on-tap/

240000187.

[40] ICANN Security and Stability Advisory Com-mittee (SSAC). Invalid Top Level DomainQueries at the Root Level of the DomainName System. SSAC Advisory 045, November2010. http://www.icann.org/en/groups/ssac/

documents/sac-045-en.pdf.

[41] ICANN Security and Stability Advisory Commit-tee (SSAC). Report of the Security and StabilityCommittee on Root Scaling. SSAC Report 046, De-cember 2010. http://www.icann.org/en/groups/ssac/documents/sac-046-en.pdf.

[42] ICANN Security and Stability Advisory Committee(SSAC). Reponse to the ICANN Board Regard-ing Interdisciplinary Studies. SSAC Advisory 059,April 2013. http://www.icann.org/en/groups/

ssac/documents/sac-059-en.pdf.

[43] ICANN Security and Stability Advisory Com-mittee (SSAC). SSAC Advisory on InternalName Certificates. SSAC Advisory 057, March2013. http://www.icann.org/en/groups/ssac/

documents/sac-057-en.pdf.

[44] J. Moss. ICANN’s April Update on SSAC046 & 057. ICANN Government Advi-sory Committee Advice, April 2013. http:

//www.icann.org/en/news/correspondence/

moss-to-falstrom-30apr13-en.

[45] Patrick S. Kane. Joint Test Summary Report,RZM. 2.0. http://www.icann.org/en/news/

correspondence/kane-to-harris-30may13-en.

pdf.

[46] O. Kolkman, A. Sullivan, and W. Kumari. A Pro-cedure for Cautious Delegation of a DNS Namedraft-kolkman-cautious-delegation. Internet draft,IETF, June 2013. http://tools.ietf.org/html/draft-kolkman-cautious-delegation-01.

[47] P. Mockapetris and K. J. Dunlap. Development ofthe domain name system. In SIGCOMM ’88, 1988.

[48] National Research Council (Etats-Unis) . Commit-tee on Internet navigation, the domain name sys-tem. Technical alternatives, policy implications,National Research Council (Etats-Unis) . Com-puter science, telecommunications board. Divi-sion on engineering, and physical sciences. Sign-posts in cyberspace : the domain name system andinternet navigation. Washington, D.C. NationalAcademies Press, 2005.

[49] Eric Osterweil, Dan Massey, and Lixia Zhang. Man-aging trusted keys in internet-scale systems. In TheFirst Workshop on Trust and Security in the FutureInternet (FIST’09), 2009.

[50] Eric Osterweil, Danny McPherson, and LixiaZhang. Operational implications of the dns controlplane. IEEE Reliability Society Newsletter, May2011.

[51] Eric Osterweil, Michael Ryan, Dan Massey, andLixia Zhang. Quantifying the operational statusof the dnssec deployment. In IMC ’08, 2008.

[52] Eric Osterweil and Lixia Zhang. Interadministra-tive challenges in managing dnskeys. IEEE Securityand Privacy, 7(5):44–51, 2009.

[53] P. Kane. Verisign Comments for NewgTLD Board Committee Consideration ofGAC Safeguard Advice. ICANN Govern-ment Advisory Committee Advice, April2013. http://forum.icann.org/lists/

comments-gac-safeguard-advice-23apr13/

msg00103.html.

[54] Keith Parkansk. How To Set Up Linux DNS Ser-vices. http://www.aboutdebian.com/dns.htm.

[55] Venugopalan Ramasubramanian and Emin GunSirer. Perils of transitive trust in the domainname system. In Proceedings of the 5th ACMSIGCOMM conference on Internet Measurement,IMC ’05, pages 35–35, Berkeley, CA, USA, 2005.USENIX Association.

[56] J. Rosenberg, H. Schulzrinne, G. Camarillo,A. Johnston, J. Peterson, R. Sparks, M. Handley,and E. Schooler. SIP: Session Initiation Protocol.RFC 3261, June 2002.

[57] F. Templin, T. Gleeson, and D. Thaler. Intra-SiteAutomatic Tunnel Addressing Protocol (ISATAP).RFC 5214, March 2008.

[58] Oracle VM VirtualBox. Ticket #11649 (new de-fect) NAT-related crash of ubuntu guest on OSXhost. https://www.virtualbox.org/ticket/

11649?cversion=0&cnum_hist=14.

[59] Jon Watson. Virtualbox: Bits and bytes mas-querading as machines. Linux Journal, 9941,February 2008. http://www.linuxjournal.com/

article/9941.

[60] D. Wessels and M. Fomenkov. Wow, That’s a lot ofpackets. In Passive and Active Network Measure-ment Workshop (PAM), San Diego, CA, Apr 2003.PAM.


Documents

New gTLD Security, Stability, Resiliency Update ...techreports.verisignlabs.com/docs/tr-1130008-1.pdf · New gTLD Security, Stability, Resiliency Update: Exploratory Consumer Impact