| Home | | | ccwhois | | | NSI ccTLD whois | | | whois.iana.org | | | IANA snapshots |
Hello all:
For your information:
As a result of several questions raised by the ccTLDs to ICANN (IANA) about the reasons to require zone file transfer to IANA, and the process they follow to review that information, ICANN issued recently a FAQ http://www.iana.org/faqs/tld-zone-access-faq.htm
After reviewing this FAQ, we find the explanation provided by ICANN to be unconvincing. If these are the reasons why IANA has refused to update the name server configuration of ccTLDs that required urgent changes, changes that were needed to avoid possible chaos caused by the sudden bankrupcy of a major ISP, we believe that, in doing so, IANA may have been risking endangering the very operational stability of the Internet it is charged to preserve.
We cannot deny that during the emergency created by the failure of KPNQuest, IANA personnel worked very hard to process the changes for many ccTLDs, but we also believe that their good work has been hampered by an unreasonable policy that has not allowed them to perform the changes for all the ccTLDs that required them. The fact that ns.eu.net is still operating has helped avoid a crisis, but this is in spite of the policy in question, not thanks to it.
We believe that the tests that IANA needs to perform to ensure the DNS operational stability and performance may be done without the requirement of zone file transfers. The two examples provided to illustrate why zone transfer would be required, namely to check that two independent name servers be provided for the sub- domains of a TLD and to check for proper format, do not survive close examination. We do agree that it is IANA's job to check that each TLD has two independent functional DNS servers (which can be tested without zone access), but we think that IANA going routinely deeper down the tree goes against the principle of delegation of authority on which the DNS is based. Furthermore, current technology makes it possible that many servers be operating using a single IP address, through the use of anycast. As far as checking that the zone file follows the proper format, we think this is not necessary nor sufficient, as some versions of BIND are not RFC 1034 compliant.
We also remain unconvinced of the need for IANA to have a copy of the zone file to allow the operation of the TLD in case of catastrophic failure. In case of a disaster, the TLD should have proper recovery mechanisms, because their operation is not limited to a single DNS server, but involves a much more complex IT infrastrucure which is needed to maintain the DNS operation. ICANN could not do anything more with the zone file than to preserve for a few hours an operation that is needed for many days in the event of a disaster and total loss of information. We firmly believe in the need to have a robust infraestructure and procedures in place to minimize the probability of this kind of failure, and to have sound contingency plans available, but the IANA policy might even work against this, by generating a false sense of security.
Since ICANN is yet to provide a reasonable explanation for the requirement to open the zone files for transfer to IANA, we understand very well the position of those ccTLD administrators that have decided not to allow such transfers. It is quite possible that allowing this transfers might create a security hole. Even if transmission could be done in a completely secure way, it would be very hard for ICANN to provide a guarantee that the storage of the zone files in its servers would not be vulnerable to the frequent attacks that those servers suffer.
Given that RFC 1591 does not explicitly require that zone files be available to IANA, and given that, until recently (two years after it appeared in ICP-1) IANA had not enforced this rule, we believe that this requirement should be eliminated. We are not against some ccTLD administrators making their zone files voluntarily available to IANA --in fact some of us do allow such access-- but we strongly reject IANA's policy of delaying urgent technical updates until it gets access to the zone file.
It would be possible to argue endlessly about whether ICP-1 is valid ICANN policy or not, given that it did not go through the proper policy development process and that it appears that the Board only approved its number, and not its substance. However, we think that this is a matter of the greatest urgency and that it cannot wait for such a discussion to be settled. There is no rule anywhere that says that IANA is forbidden to process changes of TLD name servers unless the zone file is available to it, and we call therefore to IANA to stop demanding these transfers as a precondition to make these changes. Such a step would go a long way towards showing that IANA and the ccTLDs are able to work together to achieve the goal of Internet stability that we all share.
LACTLD
Rafael (Lito) Ibarra
UCA JoseŽ SimeoŽn Can~as
San Salvador, El Salvador (SV)
Tel +(503) 210-6600, ext. 270, 271
Fax +(503) 210-6640