New gTLDs, root zone management, IANA procedures and security
Hello, We submitted the following questions in April 2009 to ICANN, http://gnso.icann.org/mailing-lists/archives/ga-200709/msg02840.html and they appear to be within your group's terms of references. Here they are again: One of the most important concerns of those commenting on the new gTLD process has been continued security of the DNS system. In light of this, I had several questions that I hope ICANN staff will undertake to answer: 1) At the present time, IANA appears to be involved in zone file changes, see: http://www.iana.org/procedures/nameserver-change-requests.html http://www.iana.org/procedures/nameserver-change-procedures.html Those pages were last updated in 2002-2003. a) While they specify ccTLDs explicitly, do those procedures apply to gTLDs currently? b) Are those the proposed procedures going forward if any new gTLDs are to be added to the root? 2) According to the ICANN Dashboard: http://forms.icann.org//idashboard/public/ in the past two years, IANA has "Root Zone Requests" of roughly 20 to 30 per MONTH on average (say 1 per day). According to the latest dot-com registry monthly report, though (page 7): http://www.icann.org/en/tlds/monthly-reports/com-net/verisign-200812.pdf Table 6.2 records that the total monthly nameserver write transactions alone was 2.49 million for December 2008, which is roughly 2% of all domains. More alarming is that 37.5 million "Modify" transactions took place (table 6.1) which corresponds to more than 40% of all domains, on average, during the month. a) In a world of thousands or tens of thousands of gTLDs, where ICANN has limited experience acting as a registrar or registry (save for their management of the root for roughly 200 top-level domains), can the procedures in Question 1 above scale to handle the increased workload? b) What are the anticipated resources that will be needed to handle the increasing number of incoming requests? In particular, will the quality of service decline for existing gTLDs if IANA faces an increased workload due to newbie gTLDs? c) Some more detailed stats from IANA might be helpful to break-down their workload either by gTLD, or by the age of the registry operator to determine whether newer gTLD operators cause a disproportionate level of work. 3) According to sections 7 and 8 of: http://www.iana.org/procedures/nameserver-change-procedures.html the US Department of Commerce receives submissions for root zone changes. a) Does this mean that the DOC can reject the addition of any new gTLDs into the root (even if ICANN or IANA approves them)? b) Given the DOC is on record opposing new gTLDs, and in light of the increased workload discussed in item #2 that would be expected, has the DOC costed out what additional resources they will need to keep up with an increased workload? 4) It's my understanding that the use of "glue records" could pose some security and/or economic (freeriding) issues. For example, if I am the owner of example.com, I can go to my registrar and create a glue record for a malevolent nameserver named "subdomain.example.com" and point it to any IP address of my choice, say 126.96.36.199. That glue record is then added to the dot-com zone file. If I own a very high traffic website say example2.com, I can have all the media files for its embedded content placed on a server at the IP address 188.8.131.52 (say http://184.108.40.206/image.gif ) but which can now be accessed at http://subdomain.example.com/image.gif . Because the IP address corresponding to that malevolent subdomain appears directly in the zone file for .com, the request is handled by VeriSign (manager of the .com zone file), and not by example.com's own nameservers (if it even has any real ones). a) Is my understanding of glue records correct, that I can offload all DNS requests directly to the registry operator above me through carefully picking which subdomain I use? b) More creatively, can a malevolent individual pick glue records corresponding to "www.example.com" (or other popular subdomains) and offload the vast majority of their DNS requests to the zone manager above them? (think for example content delivery handled by special domains like Yahoo's yimg.com for instance, which handles all their image files) c) Given (a) and (b), wouldn't a gTLD operator be able to have glue records added to offload DNS requests directly to the root zone operators, thereby "freeriding" on the root zone operators? d) With DNS queries costing $1 per 1000 requests: https://www.ultradns.net/index.php?fuseaction=order (see overage pricing) isn't it possible that there could be economic strain imposed on root server operators if their loads increased substantially (even without glue records being abused)? 5) a) What's to stop a malevolent gTLD operator from adding a glue record for "www.google.com" or "www.citibank.com" into the root zone and diverting all the traffic from the victims to an IP address of their choice? b) To answer (a) it appears that step 6 of: http://www.iana.org/procedures/nameserver-change-procedures.html would help thwart that kind of attack. However, if those checks failed (for example if procedures became fully automated), or were thwarted by DNS cache poisoning or BGP hijacking targeted at IANA, wouldn't it be *possible* for security of the root to be overturned? c) Given the importance of the root zone file, especially for the US government (.gov) and the US military (.mil), shouldn't any new program be thoroughly reviewed by security experts (including those from the US military) so that exposure to all potential new vulnerabilities is minimized? d) Would it be fair to say that increasing the number of agents and gTLDs that have access to introduce changes to the root zone file increases the probability that human error will manifest itself in a security breach? In other words, if the root zone is smaller, isn't it more secure? e) Would it be fair to say that given some potential gTLD operators have operated in grey areas of ICANN policy in the past (e.g. domain tasting, registration of hundreds of phantom/clone registrars to increase threads in domain drops or landrushes, etc.) that those same actors will not hesitate to exploit any loopholes in IANA management procedures for the root zone for their own economic benefit, to the detriment of others? f) Given ICANN/IANA has not revised IANA root zone file change procedures in 6 or 7 years (see question 1), would it be fair to say that a security audit by experts (those with more knowledge of potential loopholes than myself) is essential to ensure that the potential for commercial exploitation of any grey areas in policy is eliminated before any new gTLDs are added? I look forward to ICANN/IANA staff and the Department of Commerce's help in answering the above questions before any new gTLD is added to the root. Sincerely, George Kirikos http://www.leap.com/ P.S. It appears that when the initial comments forum was opened up, they used an incorrect email address, i.e. for the team members, not the public (I noticed it changed, so I've had to resubmit my comments). These comment errors have happened numerous times in the past -- please get your act together!