March 20, 2003

Thoughts on ICANN's long overdue CRADA report

ICANN/IANA has issued its long overdue report to NTIA entitled Public Summary of Reports Provided Under Cooperative Research and Development Agreement CN-1634 Between the Internet Corporation for Assigned Names and Numbers and the United States Department of Commerce.  This report may be found at

I have asked to see the full reports, but so far ICANN's management has not been forthcoming.  So I have no information regarding the differences between the public and private versions of the report.  I hope that the only difference is the address of the location that ICANN has selected for its god-like master server.

UPDATE: (June 23, 2003) - ICANN's management agreed to let me inspect the full report and has placed no impediments in my path. However due to limits on my own time I have not had the opportunity to actually make that inspection. However, I have reasonable confidence that the only information that was elided from the public report was of such a nature that disclosure would not promote the public interest.

This report purports to describe "Improvements to Management of the Internet Root Server System", frequently referred to as the "enhanced architecture for root server security".  The report is the result of a multi-year "Research and Development Agreement" between ICANN and the US Government.

The report as issued addresses only three small issues:

  • Establishment of a new computer to serve as a distribution point for the periodically generated master zone file image.
  • Adding a security wrapper to the method that the root servers obtain that master zone file.
  • Transferring the job of periodically generating the master zone file image from Verisign to ICANN.

Perhaps the best summary of this report was written over 2000 years ago by Horace: "parturiunt montes nascitur ridiculus mus" ("The mountain labored and brought forth a mouse.")

For truly, this report says little.  And what it does say amounts to only a few relatively minor changes to the status quo ante, hardly the kind of hoped-for hardened domain name system root that the users of the Internet deserve.

I have several questions:

  1. The report calls for ICANN to take over preparation of the root zone file.  Might it not be more appropriate for this to be a job for IANA and not ICANN?  Yes, I realize that in the minds of many observers ICANN and IANA are one entity.  However, ICANN and IANA are distinct.  ICANN performs the IANA function only as the result of it winning a contract to do so.  There is no guarantee that in the future that the IANA contract will stay with ICANN.  And thus it seems important to be clear about whether it is ICANN or IANA that has the responsibility to prepare the root zone files.

  2. Where is the agreement of the root server operators to this report?  Unless those operators agree, this report will be nothing but wasted paper.  There exists no formal relationship between ICANN (or IANA) and the root server operators; those operators are free to do what they will.  Indeed there is nothing to bind (pun intended) those operators to use any particular source of  master root zone files.  And given the recent positive and creative, but completely independent, work by the root server operators to deploy new servers (using a technique called anycast), it is not at all clear that the root server operators consider it beneficial to enter into any legally binding obligations with ICANN (or IANA.)

  3. How does this report answer the concerns raised by the distributed denial of service (DDOS) attacks against the DNS roots and the network links leading to them?  And the recent report that as many as 98% of DNS packets flowing the roots are garbage packets indicates that the roots could be strongly and negatively affected by the deployment of badly written code in consumer products.  I see nothing in the report that improves the resiliency of the DNS roots against DDOS attacks and traffic floods from poorly built equipment.  In fact, because the report suggests a single god-like master server as the source of the ultimate root zone file, it seems as if the net is being made more, rather than less, vulnerable.

  4. Another threat to DNS that has been discussed is that of affecting the routing of the net so that some or all of the root servers are left high-and-dry - operational but unable to communicate.  ISPs have built a healthy skepticism into the procedures they use when accepting routing information and as a consequence the net has a good resistance to bad routing information.  However, the routing system of the net is quite complex and there is no one who can guarantee that routing-based attacks will not occur.  In fact, with the root-server operators' adoption of anycast for the root servers, the door for such attacks may be more open than it has been in the past.  The report is silent on means to harden the net so that the DNS roots remain reachable.

  5. The report fails to consider that there might be times, such as when there is a major natural event in the vicinity of ICANN's proposed god-like master server, when it is necessary to transport copies of the root zone file by physical means, such as a CDROM.  Why does the report adopt the naive point of view that the net will always be available?  The root zone file is quite small - when compressed it occupies fewer bits than the typical image of a button on a web page.  So it would be quite easy to move it by physical means should that be necessary, but the chances of successfully doing this are greatly reduced if procedures have not been thought out beforehand.

  6. It has been considered prudent practice for operators of servers to maintain generational copies of data that has worked in the recent past.  This protects against creeping degradation of the data that may occur over several days and not be noticed until the contents of the most recent backups are themselves degraded.  A couple of years ago, when .com disappeared from the root zone, the speed at which the error propagated was constrained by the fact that the root-servers were not-time synchronized with one another with respect to the time when they updated their copies of the root zone.  The report inexplicably seems to fail to address operational procedures to deal with data rot and human errors.

  7. It is also considered prudent practice for there to be a rich diversity of server software and operating systems used by root servers.  Fortunately, the root server operators themselves have adopted some diversity in operating systems and hardware.  And one operator, as I understand it, is using something other than BIND for the actual server software.  The report, however, is silent on this issue.

  8. With regard to human errors - Verisign is rumored to have instituted a number of data quality checks on the zone files that it prepares.  This report does not indicate how, or even if, that expertise is to find its way into ICANN.  Nor does the report indicate the existence of any other accuracy checks that ICANN might apply to validate the correctness of the zone it prepares.

  9. IPv6 is becoming a victim of the chicken-and-egg syndrome.  The report does not tell us how this "enhanced architecture" is going to accommodate IPv6.

  10. Why is the report utterly silent on matters of physical security, procedures, and personnel?

  11. A root server that goes out of service for any reason, whether the cause is natural or human, is a root server that needs to be swiftly repaired and restored to service.  That takes money.  The report does not speak to the sources of such funds and how they may be made available to root server operators who might need them.

  12. The best protection is prevention.  The report does not address means through which a prospective attacker might be dissuaded from ill actions by the fear of being caught and prosecuted.  Where are the audit systems to note and log attempts to damage the root servers?  And where are the procedures to protect such information so that it is legally admissible in court should the perpetrator be found and brought to trial?

Posted by karl at March 20, 2003 11:43 AM