Top Banner

of 27

Verisign Article on NTLD

Jun 03, 2018

Download

Documents

wsonic2
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
  • 8/11/2019 Verisign Article on NTLD

    1/27

    New gTLD Security, Stability, Resiliency Update: Exploratory

    Consumer Impact Analysis

    [Verisign Labs Technical Report #1130008 Version 1.0]

    August 5, 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 mostlyjust 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 actuallylesssecurethan 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 forAssigned Names and Numbers (ICANN) [2] voted to

    release a document called The New gTLD ApplicantGuidebook. In some ways, this formally heraldedICANNs 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 snails pace. Additions of new TLDs

    were infrequent. While this wasnota 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 Commerces 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 orderof tens per year) . . . Addition of gTLDs shouldbe carried out cautiously and predictably, so that

    1

  • 8/11/2019 Verisign Article on NTLD

    2/27

    2 HOW WE USE THE DNS

    on 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 explicitlyspecify 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 ICANNsown 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 programs 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 the

    risks 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 notfullyresolved.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,.hotelin Rwanda, and.corpacross many topo-logically distributed Autonomous Systems (ASes)1 inthe Internet. We also find evidence that there may exista dependency between a popular Small Office / HomeOffice (SOHO) router vendors SIP boxes and the ap-plied for gTLD string .box. Whats more, with theintention for some applied for gTLD strings, such as.secure, to function as secure neighborhoods on theNet [39] , our risk matrix suggests that their seman-tic meaning opens them up to risk factors from cur-rent traffic that other, lower profile strings dont start

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

    off 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 .securerepresent 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 that

    its 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 servers 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 astransitive trust[50, 55] (whereresolving a simple DNS domain name could involve DNSresolution of hundreds ofotherDNS domain names), tocomplications stemming from deploying DNS Security

    Extensions (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-main names, or IDNs). As part of the Root Zone Main-tainer (RZM) role, Verisign maintains the authoritative

    c2013 VeriSign, Inc. All rights reserved. 2 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    3/27

    2 HOW WE USE THE DNS

    TLD PPM

    XXX 4018ASIA 2708KP 2588AX 2369TEL 1593UM 836

    CW 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.

    database 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 global

    failure 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.

    New gTLD PPM

    HOME 27855CORP 4085ICE 511GLOBAL 355MED 341SITE 299

    ADS 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.

    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 beread as they will never exist in the DNS. Moreover,some advice to use these strings as iTLDs is intended

    to 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;else alternative workarounds may need to be considered.

    However, many of those iTLD strings are now applied

    c2013 VeriSign, Inc. All rights reserved. 3 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    4/27

    2 HOW WE USE THE DNS

    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

    2224

    20

    1720

    31

    7

    14

    21

    12

    2219

    7

    26

    17

    22

    3839

    45

    60

    24

    22 2222

    40

    26

    13

    23

    44

    12

    2019

    39

    42

    37

    17

    24

    11

    24

    22

    2528

    18

    1613 13 12

    6

    18

    18

    32

    22

    21

    0

    10

    20

    30

    40

    50

    60

    70

    Jun-08

    Aug

    -08

    Oct-08

    Dec

    -08

    Feb-09

    Apr-09

    Jun-09

    Aug

    -09

    Oct-09

    Dec

    -09

    Feb-

    10

    Apr-10

    Jun-10

    Aug

    -10

    Oct-10

    Dec

    -10

    Feb-

    11

    Apr-11

    Jun-11

    Aug

    -11

    Oct-11

    Dec

    -11

    Feb-

    12

    Apr-12

    Jun-12

    Aug

    -12

    Oct-12

    Dec

    -12

    Feb-

    13

    Apr-13

    Jun-13

    TotalChanges

    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.

    c2013 VeriSign, Inc. All rights reserved. 4 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    5/27

    2 HOW WE USE THE DNS

    for gTLDs. This could mean that corporations that arealready dependingon these iTLDsnotbeing 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 corporations network. That is, if there isan iTLD.corp, why would one expect queries to be sent

    to 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 rootbeforebeing resolved internally.

    In fact, this issue was so fundamental to the wayDNS works, that ICANNs 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 asinvalid queries as the basis for prohibit-ing the delegation of additional strings tothose already identified in RFC 2606.

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

    GTLD-SERVERS LOCAL WWWIAB LOCALHOSTIANA NIC

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

    Alert the applicant during the string eval-uation process about the pre-existence of

    invalid TLD queries to the applicantsstring. . . .

    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 ICANNs 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.

    c2013 VeriSign, Inc. All rights reserved. 5 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    6/27

    3 GAUGING THE RISK LEVEL FOR NEW GTLD STRINGS

    PPM TLD Reserved By

    66963.9 LOCAL IETF12023.7 LOCALHOST IETF

    1740.6 INVALID IETF432.7 TLD IETF137.7 TEST IETF

    45.7 WWW IETF30.2 EXAMPLE IETF10.1 NIC ICANN

    5.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 ICANN

    0.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).

    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 likeSuper Cookies (described below). Currently, browsers(and other relying party software) download this staticfile (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 stateof 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 topartner-association.someSite.secure that anyX.509 certificate that may already exist (or even thosethat might be issued in the future [43]) for the .securestring (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 for

    New 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 riskto that user. To illustrate the seriousness of the risksposed to the end user, we begin by detailing a few illus-

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

    c2013 VeriSign, Inc. All rights reserved. 6 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    7/27

    3.2 Risks 3 GAUGING THE RISK LEVEL FOR NEW GTLD STRINGS

    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 unbounded

    exercise 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 geteasierwith 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 Apples 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 wasexpectedto 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 of

    risk, 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 todays

    RSOs. Moreover, once delegated, the registrantsundernew 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.corpex-pose network and business structure to DNS operators.So, an organization that acquires the operation of thenew.corpgTLD could potentially use its collision witheverycompanys .corpiTLD, and (in this example) beable to enumerate the numbers, types, and locations ofFoo-Enterprises 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 resolvea resources name, or possibly launch a MitM attack andpotentially siphon information (such as user credentials,passwords, etc.) from sessions associated with the do-

    c2013 VeriSign, Inc. All rights reserved. 7 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    8/27

    3.3 Threat Vectors 3 GAUGING THE RISK LEVEL FOR NEW GTLD STRINGS

    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: In Section 3.1, we discussedspecific examples of non-existent domain names beingregistered and then used to launch MitM attacks againstdomain names that already exist, albeit at much smallerscales than a gTLD. However, that existence proof could(arguably) illustrate more of lower bound on the level ofconcern, but we leave this judgment to the reader. Onemitigating factor for concerns surrounding a MitM at-tack would be if clients attempted to use some form ofend-to-end security, such as TLS [29], to protect theirsessions. However, the planned introduction of the newgTLDs has opened even TLS assurances up to attackas well. With new gTLDs, users may expect that anyMitM would be unable to spoof connections, becausewhen a user connects to a TLS service at a domain name,their expectation is that the certificate returned will bechecked and its name (either the CommonName (CN)or subjectAltName) will match that of the DNS domain

    name being used for the connection. However a recentresult has shown that this verification step is often in-correctly performed or even omitted [36], andthe intro-duction of new gTLDs may render it ineffective (evenwhen checked) anyway. A recent report by ICANNsSSAC detailed the dangers posed by Internal NameCertificates [43]. This report advised that CertificationAuthorities (CAs) have had a long-standing practice ofissuing certificates for domain names under gTLDs thatare not currently delegated. The implication of this isthatanyonecan obtain certificates for names that corre-

    spond to new gTLD strings. These certificates will havebeen issued by actual CAs, and pass all TLS verificationchecks, andmustbe considered a threat not simply untilthey are revoked, but until they expire [15]. Thus, anyTLS connection to any domain name under a new gTLDcan be properly established using a certificate that canbe easily obtained by anyone.3 From this, an adversary

    would be able to launch a MitM attack from, for exam-ple,https://www.someSite.secure.example.comtohttps://www.someSite.securebecause of a typo, ora DNS search list interaction. So, anyone in .secureoranyone using.secureas an iTLD could become vulner-able to a MitM attack.

    In addition to SAC057 [43], without the explicit scop-ing of authority codified by the rules published onPublicSuffix.org, any internal named certificate for anew gTLD could have implicit scope throughout thatentire branch of the DNS. By contrast, as we discussed inSection 2, todays DNS authority and delegation struc-ture is loosely codified in a suffix list. While this list may

    be 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 helpusers 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 DHCPINFORMquery, and uses the URL from the WPAD option inthe servers reply. If the DHCP server does not pro-vide the desired information, DNS is used. If, for ex-

    ample, the network name of the users 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 is

    3An example of this is illustrated in SAC057.

    c2013 VeriSign, Inc. All rights reserved. 8 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    9/27

    4.1 Measurement Apparatuses 4 MEASUREMENTS

    indeed 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 answeringthese queries with Webproxy information, then that operator could instruct anybrowser (or any type of WPAD client) to proxyall futureWWW trafficthrough 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 systemworks 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 gTLD

    operator (or registrant operator) were to answer ISA-TAP queries with PRLs, then clients could begin tun-nelingall 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 ofService. 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 aand j DNS root servers which Verisign operates. Thelocations of the root server instances ofaandjare 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 spreadas rep-resenting how widely a measurement is seen. Table 5illustrates the relative percentages of the overall trafficto the DNS root. One of the trends that this table showsis that, since 2006, the root system has seen queries forthe strings that are now being considered for delegationas new gTLDs. In addition, the overall trend is thatthe query traffic for them is growing. For the remainderof the text, when we discuss query measurements, if we

    c2013 VeriSign, Inc. All rights reserved. 9 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    10/27

    4.2 Spread 4 MEASUREMENTS

    Year Valid NXDomain NewQueries gTLDs

    2006 60.08% 39.92% 3.70%2007 67.28% 32.72% 2.55%2008 72.45% 27.55% 4.80%2009 72.00% 28.00% 5.52%2010 72.13% 27.87% 4.62%

    2011 65.15% 34.85% 5.22%2012 59.97% 40.03% 7.24%2013 56.98% 43.02% 8.99%

    Table 5: Relative percentages of root system traffic,measured using DITL data. Note that the New gTLDscolumn represents the percentage of NXDomain traffic.

    do not explicitly mention the source as DITL data, weimplicitly mean the source of measurement is from theaand j root servers.

    Next, we consider diversity of these queries across thelist of applied for gTLDs. Specifically, we measured thelearning rate at which we see new gTLD strings in theNXDomain traffic. Figure 3(a) shows that if you look at11 root letters combined4 it takes about 46 hours to see100% of the applied for new gTLD strings. Figure 3(b)shows the same view from a year earlier, in 2012. In thatyear, all applied for gTLD strings were observed in 46.75hours, and the individual root instances (the root serverletters) each saw only 96-97% of applied for strings in48 hours. Note the curves in Figure 3 both plot datafrom a subset of all root servers. This is because not allroot servers reported data for the DITL collection (and

    in at least one case, a root server only reported a subsetof its data). This issue serves to emphasize the theorythat these measurements (while likely an under count),require broad visibility across the root server system inorder to approach completeness and obtain an accuratemeasurement of their spread, which is key if potentiallyimpacted parties are to be assessed.

    Focusing on smaller sets of instances can protractlearning rates, and possibly skew results. Figure 4 illus-trates that almost 6 days of measurements were requiredfrom both the a and j root servers before all appliedfor gTLD strings were observed. The queries for thesestrings were seen from 26,054 distinct Autonomous Sys-tems (ASes). The relative popularity of each of the newgTLD strings (in NXDomain traffic) is plotted as a his-togram in Figure 5. This Figure illustrates the heavytailed distribution of the query load for applied for newgTLDs. Figure 6 depicts a cumulative distribution func-tion outlining the number of ASNs requesting an appliedfor gTLD string within this collection window. Figure 7illustrates the applied for strings with the highest ASN

    4The DITL data from 2013 didnt have data from two rootserver instances, so those were excluded from the calculations.

    diversity. As RFC6762 suggested, .home(11,515 ASNs)and.corp(8,555 ASNs) may in part be the result of pri-vate usage of multicast DNS, or general iTLD adoptionand use in private networks. However, other measure-ments (below) suggest that some additional applied fornew gTLD strings may have similar private usage pat-terns.

    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) .homehas 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 our

    findings. 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 newgTLDs. 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 doesnt 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 appliedfor 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. Our

    belief is that name conflicts for thoseapplied 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 inany of the applied for gTLD strings. Our metric is justone candidate quantification of this sort of behavior, andothers may choose different approaches or enhance our

    c2013 VeriSign, Inc. All rights reserved. 10 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    11/27

    4.2 Spread 4 MEASUREMENTS

    0

    0.2

    0.4

    0.6

    0.8

    1

    1min 5min 1hour 6hour 1day 2days

    CDF

    Elapsed Time

    How long does it take to see some percentage of proposed gTLDs in 2013 DITL data?

    ACDEFHIJKL

    MALL

    (a) This Figure shows the CDFs of the learning rate of newgTLD strings for each root instance (as seen in 2013), anda cumulative curve across all of them. It shows that withinabout 46 hours, all new gTLD strings are observed.

    0

    0.2

    0.4

    0.6

    0.8

    1

    1min 5min 1hour 6hour 1day 2days

    CDF

    Elapsed Time

    How long does it take to see some percentage of proposed gTLDs in 2012 DITL data?

    ACEFHIJKL

    MALL

    (b) This Figure shows the CDFs show the learning rate of newgTLD strings for each root instance (as seen in 2012), and acumulative curve across all of them. It shows that within 46.75hours, all new gTLD strings are observed.

    Figure 3: These Figures show that the number of applied for new gTLD strings observed (100% of the applied forstrings), and the rate at which they are discovered are almost identical in DITL measurement from both 2012 and2013. Further, these DITL measurements do not even account for all of the DNS root servers, and are thereforelikely an under count.

    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.

    c2013 VeriSign, Inc. All rights reserved. 11 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    12/27

    4.2 Spread 4 MEASUREMENTS

    0.1

    1

    10

    100

    .home

    .corp.ice.prod.ads.global

    .cisco

    .inc.host

    .hsbc

    .mail

    .dev.networ

    .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.010.1

    1

    10

    100

    0 2004006008001000

    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).

    approach. 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 regionthat 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 regionsnormal 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 (igTLDr ), we first calculate the total numberof queries that each region r issues for all new gTLDsQr. Table 6 shows some example query counts for some

    gTLDs, 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 givengTLD from a specific region r, andigTLDr represents therelative query fraction seen for a specific gTLD in regionr. Table 7 illustrates how this normalizes the query ratesseen from each region, for each applied for gTLD.

    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.

    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 mirror

    c2013 VeriSign, Inc. All rights reserved. 12 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    13/27

    4.2 Spread 4 MEASUREMENTS

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

    c2013 VeriSign, Inc. All rights reserved. 13 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    14/27

    4.2 Spread 4 MEASUREMENTS

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

    1000

    10000

    100000

    1e+06

    1e+07

    1e+08

    HOME

    CISCO

    BOXCORP

    PROD

    SITESFROFFIC

    BLOG

    WOWGOLD

    DEVWEBSMART

    IINET

    TAOBA

    CASA

    SAMSU

    ZIPGOOG

    NETW

    INCSCHO

    MAILWORL

    Top 25 Unique Second Level Domains (SLDs) Under gTLDs

    0.1

    1

    10

    100

    1000

    10000

    100000

    1e+06

    1e+07

    1e+08

    0 2004006008001000

    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 gTLD strings.The large plot shows the top 25 applied for gTLDs, and the smaller plot shows the entire distribution of appliedfor strings.

    c2013 VeriSign, Inc. All rights reserved. 14 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    15/27

    4.2 Spread 4 MEASUREMENTS

    0

    500

    1000

    1500

    2000

    2500

    3000

    3500

    4000

    4500

    5000

    website

    google

    yahoo

    devhotm

    ail

    linkgm

    ail

    youtube

    news

    bloghom

    e

    amazo

    shopcontact

    web

    skinsearch

    aolmail

    sitewebs

    pagehere

    media

    aaa

    Top 25 HTML Links Found for Each New gTLD

    0.1

    1

    10

    100

    1000

    10000

    1 10100

    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.

    c2013 VeriSign, Inc. All rights reserved. 15 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    16/27

    4.2 Spread 4 MEASUREMENTS

    each 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 (igTLDr ) that is more than twostandard deviations (2 gTLD) away from the averageinterest across all regions IgTLD. That is, we define anapplied for gTLDs overall interestIgTLD as the average

    of all regional interests for that gTLD:

    IgTLD =

    |R|i=1i

    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,.sfrhas 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 .winand .iinetreceive 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 alternatives

    or 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 a

    snapshot 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 possibil-ity that applied for new gTLD strings are already in use

    by automated systems, whose traffic may display mea-surable periodicity. That is, we speculate that some sys-tems (such as, monitoring systems or embedded devices)may periodically beacon out DNS queries. So, we mea-sured the inter-query time gap for each query to eachapplied for gTLD from each AS, and then calculatedthe variance for each time series. Our intuition is thatwhen queries are emitted at roughly the same rate overtime, the variance in this value should be low. Underhigh concurrency, one might expect low variance scores(as query rates would approach the inverse of the TTLperiod: = 1

    TTL). Under lower concurrency, our hy-

    pothesis is that similarly low variance scores might sug-

    gest some degree of weak signal (perhaps automation).What we find from measurements is that some of ap-plied for gTLDs strings with the greatest query volume(such as.corp) do indeed have very low variance scoresfrom large ASes (such as Verizon, Rackspace, DeutscheTelekom, etc.). Our interpretation of this metric is thatit offers an additional piece of evidence that some ASesmay have a reliance on applied for gTLD strings.

    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 butcouldalso (in at least one particular case, discussed be-low) prompt crashes in VirtualBox [59] (a popular brandof virtual machine). Below the fritz.boxdomain, 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-

    c2013 VeriSign, Inc. All rights reserved. 16 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    17/27

    4.3 Impact 4 MEASUREMENTS

    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.76

    Paraguay (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.

    eral failures could be caused behind SOHO routers. Ina ticket listed in the the bug tracking system for Ora-cles 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 Googles public DNS resolu-tion (8.8.8.8), and this correlates well with our measure-

    ments. We observe that Googles 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.

    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 activelyrelied upon. Other periodic trends include .ice fromMicrosoft, or .maif from British Telecommunications.Each of these applied for gTLD strings have varyingtraffic patterns across their constituent ASes, but thismetric helps identify which ASes may be more system-atically 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 11

    c2013 VeriSign, Inc. All rights reserved. 17 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    18/27

    4.3 Impact 4 MEASUREMENTS

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

    c2013 VeriSign, Inc. All rights reserved. 18 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    19/27

    4.3 Impact 4 MEASUREMENTS

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

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

    c2013 VeriSign, Inc. All rights reserved. 19 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    20/27

    4.3 Impact 4 MEASUREMENTS

    Figure 13: This Figure shows popular SLDs within.cisco. The labels .isatap, .wpad, and . udp and . tcpcould directly indicate threat vectors, but are certainly not the only SLDs that could be problematic.

    c2013 VeriSign, Inc. All rights reserved. 20 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    21/27

    4.3 Impact 4 MEASUREMENTS

    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.

    c2013 VeriSign, Inc. All rights reserved. 21 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    22/27

    5 SECURITY ANALYSIS: HOW PERVASIVE IS THE RISK?

    shows 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 likeAirBus, which could indicate a dependency on NXDo-mains by a large aerospace manufacturer. Or, considerAD, which has been used by some as an Active Direc-tory control point [7]. Furthermore, our measurementsshow evidence that (due to the nature of WPADs 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 that

    could be drawn from the most popular SLDs under.cisco, seen in Figure 13. Here we can see that notonly is wpadthe second most popular SLD, but isatapis number one. Moreover, DNS-SD-like labels (. udpand . 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 re-ceived requests of the form isatap.*.gTLD. Fig-ure 14 shows the most requested ISATAP gTLDs bydistinct ASNs. This data shows that applied for gTLDstrings are 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-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 ofhowthey 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 HTML

    links 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 resultsbased on the number of our risk factors that each ap-plied for new gTLD string triggered, and the relativespread observed. Table 9 enumerates just those newgTLD strings that appeared to have the most measur-

    c2013 VeriSign, Inc. All rights reserved. 22 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    23/27

    5 SECURITY ANALYSIS: HOW PERVASIVE IS THE RISK?

    gTLD WPAD ISATAP DNS-SD X.509 HTML Total Risk ASN High Regional

    ASNs ASNs ASNs Certs References Vectors Spread Affinities

    MEDICAL 83 59 202 1 12 6 0.70915 JP: 7.844514614PR: 10.49906116

    CORP 3744 2984 5020 378 130 6 0.652718 AP: 4.342243987GT: 2.326143183HN: 4.238233141HR: 3.474233373HU: 3.423658734LV: 2.011148834NI: 2.889416268

    BOX 631 1588 702 53 36 6 0.645921 MQ: 12.27307911NA: 7.077975841

    HOTEL 112 233 128 1 39 6 0.609756 RW: 3.15269427UZ: 13.42401684

    NETWORK 679 1026 778 39 28 6 0.605605 DK: 2.976043488FI: 13.79893113

    GROUP 653 565 925 22 27 6 0.600437 RW: 3.890205193TG: 12.55667782

    GLOBAL 912 742 1305 21 18 6 0.59789 AT: 3.15186194FI: 2.040087011GT: 5.625706492KR: 6.056511404MN: 2.785921935SE: 7.726523122SK: 2.359681194

    ADS 782 614 1199 79 43 6 0.566077 FR: 6.0475191RE: 11.71323549

    HOUSE 169 175 150 3 49 6 0.55511 BN: 6.709764611PR: 8.545697807PY: 3.932239004UY: 2.243063525

    OFFICE 648 610 884 659 33 6 0.547196 EU: 8.77829226GP: 3.197014635HU: 3.33735979MK: 3.295567945PR: 3.620329369UA: 2.392505739UZ: 4.234508738

    OLYMPUS 131 94 127 3 2 6 0.533875 AT: 2.192795664CU: 9.67578374SK: 3.744805942

    SCHOOL 156 192 232 2 39 6 0.531303 AE: 3.832630133AU: 3.064137412MV: 9.959716579NZ: 3.045171468TW: 5.338130997

    GMBH 26 21 62 7 2 6 0.522388 AT: 3.273191864DE: 8.400470589HR: 2.899925318

    DENTAL 42 34 37 2 5 6 0.512605 AT: 9.947306743LLC 214 174 213 2 11 6 0.495327 MN: 14.21405373SOLUTIONS 31 29 41 2 36 6 0.478261 LV: 10.78762702CLINIC 35 33 43 1 4 6 0.471074 CY: 11.90023861MOSCOW 18 34 21 2 3 6 0.464286 AE: 6.012328648

    CY: 4.928083601HSBC 274 68 409 9 7 6 0.459067 GT: 5.585119448HN: 12.29934347SV: 2.284495796

    SECURITY 38 27 41 1 14 6 0.168246 AO: 8.620230628LT: 4.639229932MM: 5.195470483

    SECURE 47 64 59 1 65 6 0.0850877 LV: 2.739786598SK: 11.43976024

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

    c2013 VeriSign, Inc. All rights reserved. 23 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    24/27

    7 CONCLUSION

    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 of po-tential issues that may arise with the delegation of theapplied for new gTLDs (and new TLDs in general). Be-yond this, it is our belief that constructive recommenda-tions can be issued and followed to help mitigate prob-

    lems that may lie ahead, and we enumerate a candidatelist here. At a high level, we simply recommend thatICANN implement those recommendations that wereoutlined in the Signposts in Cyberspace, [48], Scal-ing the Root study [19], SAC045 [40], SAC046 [41],SAC057 [43], and SAC059 [42]. These are all work prod-ucts which we have, in various capacities, participateddirectly in over the past decade. Specifically, these rec-ommendations are, at a high level:

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

    the 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 havent 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. This

    is 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-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 global

    DNS.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 those

    c2013 VeriSign, Inc. All rights reserved. 24 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    25/27

    REFERENCES REFERENCES

    responsible for giving due consideration to (and imple-mentation of) recommendations provided by ICANNsadvisory 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 the

    most 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. InMozilla 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. InICANN, June 2012. http://newgtlds.icann.org/EN/APPLICANTS/AGB.

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

    [12] Apple, Google and Microsoft still dont understandnew TLDs. InDomain 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 (doesnt) 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.

    c2013 VeriSign, Inc. All rights reserved. 25 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    26/27

    REFERENCES REFERENCES

    [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. GLOBECOM01.IEEE, volume 3, pages 16721676. 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 Presidents 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 layer

    security (tls) protocol version 1.2. RFC 5246, 2008.[30] D. Eastlake and A. Panitz. Reserved Top Level

    DNS 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 - Everythings 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 3849, 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 Internal

    c2013 VeriSign, Inc. All rights reserved. 26 Verisign Labs Technical Report #1130008

  • 8/11/2019 Verisign Article on NTLD

    27/27

    REFERENCES REFERENCES

    Name Certificates. SSAC Advisory 057, March2013. http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf.

    [44] J. Moss. ICANNs 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-