name-collision-02aug13-en

More documents

Recommendations

Info

organizations that operate as widely-trusted certification authorities (i.e., those with root certificates embedded in browsers and OSs); and web browser and other software vendors. 3.4.2 Data sources and root server assistance Preliminary discussions on the practicalities of this study took place during the RIPE66 and DNS-OARC meetings in mid-May 2013 since several of the RSOs were attending. These discussions considered what data would be needed for the study, how to collect and deliver that data, likely timelines/milestones, and what levels of assistance the RSOs could provide. The consensus was that the main data source for DNS analysis should be DNS-OARC’s DITL (Day in the life of the Internet) 15 data sets. Many RSOs already contributed data to that initiative and had begun preparations for the 2013 DITL exercise which would start later that month. Using DITL data for this study had the benefit of not requiring RSOs to commit resources for some other type of data gathering. In addition, access to the DITL data was covered by a single data sharing agreement common to all DNS-OARC members. This meant that the study team would be able to analyze those data almost immediately and avoid the potential delays that might arise from the legal complexities of arranging confidentiality and/or data access agreements with individual root server operators. 3.4.3 DITL data processing The sheer size of the DITL data sets presented many challenges; managing roughly 8TB of compressed data spread across more than 500,000 files and organizing the workflow around them was a non-trivial exercise. All of this work had to be performed at DNS-OARC under the terms of its data sharing agreement. DITL data could not be copied or moved off-site; they could be accessed only across the local network from DNS-OARC’s file servers. Before any data gathering was carried out, the team made an assessment of the available hardware at DNS-OARC and the potential software that could be used. Some benchmarking was done to assess the hardware or network footprint of these tools and how long particular tools would take to process the data. Pragmatic choices were then made about how best to proceed— which tools would be most suited to the available platforms; what approaches to processing the data would and would not work well; how to arrange the workflows; and estimating how long each run over the data sets would take. Appropriate scripts were then developed and tested. These produced summary results which were submitted for statistical analysis. 15 https://www.dns-oarc.net/oarc/data/ditl Name Collision Study Report Page 18 Version 1.5 2013.08.02
Processing of the DITL data was carried out in two stages. The first pass over the data just counted TLD labels: how often a string appeared as the right-most label of the QNAME in each DNS request. The second pass extracted information about DNS requests that contained any label matching one of the proposed gTLD strings. This filtering reduced the data sets for analysis from terabytes of compressed data in wire format to gigabytes of plain text. Each pass over a year’s DITL data took approximately 1 calendar week. In reality, processing for each data run took 2 CPU-months, since all of the CPUs of an 8-core system were used in parallel. A custom version of packetq was used to produce counts of the TLD labels. The second run over each DITL data set generated plain text which could then be processed by the usual UNIX tools: awk, sed, perl, etc. Scripts processed the plain text to produce summary reports on label position and source address prefix counts for each proposed gTLD. Each script run took about 16 hours of elapsed time (approximately 12 CPU-days). The graphs and tables in this report were created from these summaries. The 2013 DITL exercise took place at the end of May 2013. Delivery of 2013 DITL pcap files was under way while processing of the 2012 DITL data was in progress. The summary reports from the 2012 data set were completed on June 18th. By then the 2013 DITL data had arrived at DNS-OARC. Analysis of this year’s data began on June 19th and production of the summary reports from those data runs and scripts was completed on June 26th. Comparable data runs were carried out on global resolver provider data that were contributed to DITL in 2012. A script was used to count TLD labels instead of using packetq because name server log files in plain text had been provided rather than raw packet format pcap files. Some verification of the summary reports was carried out. A small amount of data sampling was done to check that the summary findings were reasonably accurate and no scripting errors had been introduced. In addition, an independent analysis of the I-root pcap files was carried out at Netnod. This produced results that were broadly in line with those produced by this study across all the RSOs who had contributed to the 2012 and 2013 DITL exercises. Further analysis counted the settings of the opcode field and RA and RD bits in the DNS requests. 3.4.4 Acknowledgements The study was conducted by Lyman Chapin, Olaf Kolkman, Jim Reid, Colin Strutt, and Chuck Wade. Patrik Fältström served as liaison between the study team and SSAC. Special thanks are extended to kc claffy for making a CAIDA 16 system installed at DNS-OARC available to the team so that the DITL data could be processed. It would not have been possible 16 The Cooperative Association for Internet Data Analysis (http://www.caida.org). Name Collision Study Report Page 19 Version 1.5 2013.08.02
Page 1 and 2: Name Collision in the DNS A study o
Page 3 and 4: necessary to definitively establish
Page 5 and 6: Contents Executive Summary ........
Page 7 and 8: 9.4.3 Residual risk................
Page 9 and 10: 1 Introduction A name that is prope
Page 11 and 12: How widespread is the use of intern
Page 13 and 14: The root zone contains pointers dow
Page 15 and 16: indistinguishable, and few user int
Page 17: On 28 May 2013 ICANN announced 12 t
Page 21 and 22: 4 Name collision potential The key
Page 23 and 24: Rank String Count (thousands) 24 re
Page 25 and 26: Rank TLD Existing TLD Proposed TLD
Page 27 and 28: Rank TLD Existing TLD Proposed TLD
Page 29 and 30: Rank 2012 2013 Change Proposed TLD
Page 31 and 32: Rank 2012 2013 Change Proposed TLD
Page 33 and 34: Rank String Count (thousands) Prefi
Page 35 and 36: For most of the proposed TLDs for w
Page 37 and 38: Total a c e f h i j k l m star 12 1
Page 39 and 40: Resolver rank DITL2103 rank TLD Exi
Page 41 and 42: Resolver rank DITL2103 rank TLD Exi
Page 43 and 44: 4.3.3 Weighting of resolver traffic
Page 45 and 46: 5 Name collision etiology The scope
Page 47 and 48: Proposed TLD usage all a-root c-roo
Page 49 and 50: Apparently the Google Chrome browse
Page 51 and 52: _sipinternaltls._tcp. _sipfederatio
Page 53 and 54: 6.1.1 Name lookup ambiguity Suppose
Page 55 and 56: 6.1.3 Non-query DNS traffic Althoug
Page 57 and 58: when local policy was to validate a
Page 59 and 60: signed, the relying party can confi
Page 61 and 62: significantly extend the range or s
Page 63 and 64: that the CA’s cert is distributed
Page 65 and 66: implications when certs are utilize
Page 67 and 68: credentials, perhaps as a prelude t
Page 69 and 70:
Assuming that a comprehensive risk/
Page 71 and 72:
Proposed TLD A AAAA MX PTR SRV TXT
Page 73 and 74:
Proposed TLD A AAAA MX PTR SRV TXT
Page 75 and 76:
Mozilla organization, and a survey
Page 77 and 78:
8 Name collision risk assessment Ri
Page 79 and 80:
8.3 Risk assessment framework The r
Page 81 and 82:
For example, this report (and other
Page 83 and 84:
The gradient plotted in Figure 4 is
Page 85 and 86:
9.1.1 Advantages A permanently rese
Page 87 and 88:
9.4 Look before you leap Verisign [
Page 89 and 90:
10 References [1] Invalid Top Level
Page 91 and 92:
Appendix A—Complete 2012 Counts T
Page 93 and 94:
Rank Proposed TLD As TLD As SLD At
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
25 169 sap 1,735 18,189 556 20,480
Page 137 and 138:
95 124 bom 251 64 348 663 96 50 ibm
Page 139 and 140:
165 115 moe 110 179 391 680 166 145
Page 141 and 142:
235 182 space 62 571 108 742 236 17
Page 143 and 144:
305 320 cool 44 21 55 120 306 436 i
Page 145 and 146:
375 404 lat 31 37 116 183 376 329 g
Page 147 and 148:
445 416 ping 22 46 704 772 446 377
Page 149 and 150:
515 619 ira 16 21 74 110 516 449 ri
Page 151 and 152:
585 594 financial 11 61 9 81 586 59
Page 153 and 154:
655 514 agency 8 58 154 220 656 450
Page 155 and 156:
725 714 chloe 6 3 5 14 726 894 reis
Page 157 and 158:
795 745 realty 4 21 90 115 796 803
Page 159 and 160:
865 923 banque 3 2 9 14 866 1015 fe
Page 161 and 162:
935 870 jmp 2 30 7 40 936 987 montb
Page 163 and 164:
1005 1025 tatar 1 10 5 16 1006 973
Page 165 and 166:
1075 1161 mutuelle 1 4 1 6 1076 976
Page 167 and 168:
1145 1169 lancome 0 2 5 7 1146 1186
Page 169 and 170:
1215 1256 xn--ngbc5azd 0 0 0 0 1216
Page 171 and 172:
1285 1267 kyknet 0 0 0 0 1286 1325
Page 173 and 174:
1355 n/a allfinanzberatung 0 0 0 0
Page 175 and 176:
Appendix C—Internal Name Certific
Page 177 and 178:
Proposed TLD 2013 2014 2015 2016 20
Page 179 and 180:
Proposed TLD 2013 2014 2015 2016 20
Page 181 and 182:
Appendix E—Top 25 by Root Server
Page 183 and 184:
Appendix G—SLD is an Existing TLD
Page 185 and 186:
Appendix I—TLD and SLD are both a
Page 187 and 188:
Appendix K—QNAME is www.ProposedT
Page 189 and 190:
Appendix M—LDAP and Kerberos name
Page 191 and 192:
Appendix O—_dns-sd DNS names (201
Page 193 and 194:
ice link google red mail smart worl
Page 195 and 196:
star mail ltd google sap app world
Page 197:
Appendix S—10-character SLD with
show all

name-collision-02aug13-en

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?