Draft Comment on ICANN AXFR Requirement for ccTLDs

 

Editor: Kim Davies, kim@centr.org

25 June 2002, Version 1.0

 

 

Background

----------

 

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:

 

RFC 1591 -- http://www.ietf.org/rfc/rfc1591.txt

   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.

 

ICP-1 -- http://www.icann.org/icp/icp-1.htm

   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.

 

Implementation of the policy

----------------------------

 

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.

 

Usefulness of the policy

------------------------

 

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.

 

Security and Legal implications

-------------------------------

 

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.

 

Going Forward

-------------

 

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.

 

Conclusions

-----------

 

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.