| Home | | | Meetings | | | AdCom | | | ccTLD | | | Participants |
Editor: Kim Davies, kim@centr.org
25 June 2002, Version 1.0
The recent uncertainty regarding the operation of a key authoritative name server in Europe, operated by KPNQwest, has provoked many ccTLDs to initiate changes to their name server records in the root zone. These changes have been submitted to IANA using the documented procedure. However, such requests have been denied if the ccTLD does not permit IANA to download their zone files routinely using an AXFR request.
We are informed this new requirement of IANA stems from these paragraphs:
There must be a primary and a secondary nameserver that have IP connectivity to the Internet and can be easily checked for operational status and database accuracy by the IR and the IANA.
Because of its responsibilities for the DNS, the IANA must be granted access to all TLD zones on a continuing basis. There must be a primary and a secondary nameserver that have IP connectivity to the Internet and can be easily checked via access to zones for operational status and database accuracy by the IANA.
The requirement for zone file access was only recently introduced. ICANN's operating procedure, ICP-1, was referred to in ICANN board resolution 02.10 on 12 February, 2002. It is unclear what status this affords the document and whether it has been explicitly approved as an operational policy by the board. However, ICP-1 was never considered or approved by the ccTLD community and thus has not gained widespread support. Many ccTLDs only recognise RFC 1591 as the authoritative document on ccTLD management.
To our understanding the provision in ICP-1 to demand zone file access from ccTLDs has only been applied in the past few months. This is unclear, as there was no consultative process or forewarning about the change in obligations that ICANN was imposing on ccTLDs.
In June 2002, the future of large telecommunications carrier KPNQwest came into doubt. KPNQwest operated a secondary name server for over 60 ccTLDs. Mindful to ensure stability of the DNS, many ccTLDs took the step to remove their reliance on KPNQwest nameservers by either removing KPNQwest secondaries, or replacing them with those on another network.
After initial consultation with IANA, ccTLDs submitted applications for simple nameserver changes. Most of these applications were then rejected for failing to meet the zone transfer requirement in ICP-1.
Our key criticism is the fact that during a time of potential Internet instability, ICANN steadfastly insisted that ccTLDs comply with a controversial new requirement of which they knew little about. This insistence of opening zone transfers to ccTLDs had the opposite effect to the goals it sought to achieve. It potentially decreased the stability of the DNS by not allowing critical changes to go through.
Leaving aside the procedural and political issues associated with the introduction of this policy, we have considered the merits of this new demand. However, at this stage we are not convinced of any useful tests that could be conducted on ccTLD zones for "operational status" and "database accuracy," that weigh up against the drastic step to enable zone transfers from the authoritative name servers.
Tests for operational status and database accuracy can be conducted without need for a zone transfer. Whilst some tests could be conducted on the zone file - such as for syntactic correctness - we do not believe they are of sufficient importance to justify the need for zone transfers. Our belief is IANA's key compliance testing should involve comparing the IANA database and root zone delegations, with the data served by the ccTLD authoritative name servers.
ccTLDs can and do monitor their own zone files to ensure technical best practice and to identify potential performance errors. It is accepted that IANA/ICANN provides technical advice and support to some ccTLDs, and in the course of providing some services zone access is required. However we are of the opinion that such access need only be voluntarily provided by the ccTLD.
If the zone transfer requirement is proven to be essential for ensuring the ongoing operation of the DNS, we believe the method of zone transfer is irresponsible from a security perspective. Allowing unauthenticated access to the zone from a large IP address block is not ideal, and there is no indication of what other methods are employed to ensure data protection by ICANN.
There are also concerns about the ccTLDs legal right to provide this information to ICANN. In various parts of the world, such as the European Union, tight data privacy laws limit the capability of registries to share their customer data, especially to other countries.
CENTR has now sought clarification from ICANN on the new requirements in order to further consider these issues, with a view to working with ICANN to revise IANA's operating procedures to better reflect the requirements for ensuring stable operation of ccTLDs.
We naturally support efforts to ensure DNS integrity and the correct function of the DNS system. However we believe this must be done in a responsible and accountable manner. Explicit technical best practice policies should be developed for the operation of ccTLDs in this area. Thought must be given to what role IANA, ccTLD managers and registries will play in the adoption and monitoring of compliance with these policies.
The IANA zone transfer requirement has been introduced with no consultation of our members, and to our knowledge, without thorough analysis.
We believe ICANN's method of introducing such a contentious change in policy is unacceptable. It contradicts the principle of bottom-up participation, and has been forced upon our members at a time when there was a compelling requirement to ensure nameserver changes were made expediently. This demand has delayed and confused this process at the risk of decreasing the stability of the Internet - contrary to the very aims of the policy.
We can not understand how ICANN, an organisation that needs to demonstrate it's legitimacy and improve its working relationship with a sceptical ccTLD community, can perform in the way it has. We object to the fact we even need to debate these policy changes under the threat of loss of DNS stability. The way this matter has been handled is a textbook example of why there is huge concern within the ccTLD community over ICANN's involvement in both policy and administrative matters.
We look toward creating an efficient and well-supported IANA function, which allows us to make timely changes to DNS records, ensures a stable DNS system, and considers the implications of its policies. Most importantly, we look forward to a situation where ccTLDs and IANA work in a trusting partnership to fulfil their common goals.