[ga] New gTLDs, root zone management, IANA procedures and security

[George Kirikos <gkirikos@xxxxxxxxx>]

Hi folks,

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 123.45.67.89. 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 
123.45.67.89 (say http://123.45.67.89/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/