[ga] CENTR Reaction to IANA Zone Access FAQ

[Kim Davies <kim@centr.org>]

This is our response to the IANA Zone Access FAQ. It is also online
at http://www.centr.org/news/ICANN-Zone-Access-Comments.html
--kim



                 Draft Comments on ICANN Zone Access Policy

                          CENTR Executive Committee
                              26 September 2002


Historical Background
---------------------

Historically, all Internet zones were available to retrieve using the AXFR
protocol without restriction. In earlier name server implementations, in
fact, there was no provision to limit the distribution of zones to a
restricted set of name servers.

As a result of undesirable use of this data, DNS managers requested that
the facility be incorporated into name server software to allow zone
transfers to be limited.

It is now best current practice to limit AXFR access to zone files. This is
not just limited to top level domain zones, but also in universities,
businesses, and other organisations where potentially sensitive information
can be interpreted by allowing the entire zone to be retrieved.

In May 2002, a number of ccTLD Managers moved to reduce their exposure to
problems being experienced by dominant Europe Internet provider KPNQwest.
This included a heavy reliance on ns.eu.net, a secondary name server that
was used by over 60 ccTLDs.

When redelegation requests were sent to IANA, a number of these urgent
requests were not processed. IANA would not allow the redelegations to
proceed unless the TLD name servers were reconfigured to permit zone
transfers to a large IANA network.

CENTR, based upon lengthy discussions involving all ccTLDs in Bucharest,
released a statement on this requirement (see
http://www.centr.org/news/ICANN-AXFR.html)

ICANN, currently responsible for conducting the IANA function, has
responded to the questions and statement in the form of an IANA "Frequently
Asked Questions" document <http://www.iana.org/faqs/tld-zone-access-
faq.htm> which was posted on their website on September 5th.

This document addresses our opinion on the answers given to these
Frequently Asked Questions, and how they impact the initial concerns we
raised with ICANN on this matter in June 2002.


1. Technical Reasons for Zone Access
====================================

ICANN has not, to our knowledge, provided use with a comprehensive list of
the tests IANA conducts on ccTLD zones. Rather it has given two examples on
what zone file access can provide.

These two examples are: checking that domains delegated under the ccTLD
have at least two name servers, and checking that the "master file" meets
the format set out in STD 13.

We believe ICANN does not demonstrate these are technical problems that
either substantially threaten the stability of the Internet, or are in the
province of IANA to monitor and repair.


Two Nameserver Requirement
--------------------------

ICANN's first technical justification states it plays a role in ensuring
zones on the second level (those delegated underneath ccTLDs) operate at
least two name servers. This policy implies a broad-reaching role for ICANN
to act as the police of the DNS tree. This decision to descend to this
level seems arbitrary. ICANN seems to be expanding its mission to take
responsibility for administration of DNS zones outside their mandate, which
contravenes the principle inherent in the DNS of delegating authority.

The two NS record requirement doesn't take into account modern technical
practices, such as anycast addresses where the number of name servers can
be higher than the number of NS records.

We strongly believe it is not incumbent on IANA to force the two name
server requirement on anyone other than their immediate delegates (i.e.
those listed in the root zone), and therefore they do not need to test this
requirement within TLD zones. They may analyse other zones if they wish,
but this must be on a voluntary basis only.


Checking Zone Syntax
--------------------

The other technical justification in the FAQ is to test the "master file"
format complies with STD 13 (RFCs 1034 and 1035).

Any such requirement is based on obsolete procedures and practices that are
largely irrelevant in today's Internet.

* Version 9 of BIND (the current standard release) uses a zone file format
  that is in part not in compliance with RFC 1034 and 1035 yet still carries
  out its function appropriately.

* The version of the zone file ICANN would received through a zone transfer
  can materially differ from any original "master file" as it is reprocessed
  through the name server.

* Recent versions of BIND and other name server software will not permit
  syntactic and semantic errors in a zone file to pass.

* Increasingly, name servers can avoid the existence of any such master file.
  Name server responses could be generated, for example, directly out of an
  SQL database where an RFC 1035 type zone file never exists.

* The concept of dynamic DNS means that a master file could realistically
  differ to the data actually being served by the name servers at any given
  time.

In essence, it is simply not necessary for a name server, or ccTLD, to
operate from a STD 13 style master file in order to carry out its function
correctly.

Any argument that IANA must test for these standards is, we believe, based
on false assumptions and is outside IANA's scope.


2. Legal Issues
===============

In addition to the lack of technical argument to justify the need for zone
files, there are a number of legal implications that arise from the zone
transfer policy.


Data Escrow
-----------

Despite prior assertions to the contrary, ICANN has now stated in this
document that IANA intends to use zone transfers are used as a method for
data escrow.

This policy change is of utmost concern to us. Data security and disaster-
recovery mechanisms are matters of good practice that all ccTLDs should
employ, however it must be using locally developed or tailored policies.

Delicate issues such as data protection laws vary from country to country,
and the appropriate legal and responsible way to manage data must be
determined on a local level. For many ccTLDs it is only appropriate to
provide such data and responsibility to a party in their country (or the
EU) which is subject to the same laws as the ccTLD manager.


Breach of Data Protection Laws
------------------------------

It is our considered view that providing zone files to ICANN would
constitute a breach of data protection laws that cover many jurisdictions
within Europe. Although the EC directive 95/46/EC is implemented
differently throughout Europe, the underlying principles are identical.


Protection for Database Compilers
---------------------------------

The Directive 96/9/EC of the European Parliament on the legal protection of
databases empowers the creator of any database which requires the
investment of considerable human, technical and financial resources, when
said database can be replicated at considerably less expense.


As registries have a duty as trustees of a database that has been developed
by and for the local community, they have a responsibility to use this
power to protect the database against undesirable use by third parties.


Economically Sensitive Data in Zone Compilations
------------------------------------------------

There is potentially sensitive economic information that can be inferred
from the zone data. For example, by ranking domains associated with
particular name servers, one could infer a league-table of ISPs and
registries.  Also, access to the zone could reveal unique information not
available to the public - such as the registration of a domain for a new
unreleased product by a company.

If the registry consented to the release of the zone, which resulted in the
publication of such data, domain name holders could hold the registry
liable for any resulting damages.


Undue Burden on IANA: Disaster Recovery
---------------------------------------

ICANN asserts IANA has a role to play in operating a ccTLD in a case of
last resort, and the zones provide them the power to do this.

We believe this places undue burden and liability on IANA that confuses its
key role of technical co-ordination. Operating as a ccTLD Registry, even on
an interim basis, exposes IANA to many undesirable consequences under law -
including exposure to legal liability under the laws of the country the
ccTLD represents.

IANA's role should be strictly defined as a technical co-ordination body,
not as a surrogate ccTLD manager.


Undue Burden on IANA: Generic DNS Monitoring
--------------------------------------------

IANA's declared role in checking that second level domains have two or more
name servers clearly steps over the separation of authority between the
root zone, and the ccTLD zone. IANA assumes an extra burden and legal
exposure if they their role is to police DNS data outside their specific
mandate of operating the root and ensuring accurate delegations within the
root.


Breach of Contract by ICANN
---------------------------

In the contract entered into between ICANN and the United States
<http://www.icann.org/general/iana-contract-09feb00.htm> ICANN undertakes
the following responsibility of

      ...facilitation and coordination of the root zone of the domain name
      system. It includes receiving requests for and making routine updates
      of ccTLD contact and name server information. It also includes
      receiving delegation and redelegation requests, investigating the
      circumstances pertinent to those requests, and reporting on the
      requests. This function, however, does not include authorizing
      modifications, additions, or deletions to the root zone file or
      associated information that constitute delegation or redelegation of
      top-level domains.

In relation to the DNS, the terms "delegation" and "redelegation" are
technical terms referring to the entry (or change of entry) of name server
records, the so called "routine updates of name server information."

It is incumbent upon ICANN on our reading of this contract to fulfil such
requests except those that amount to a reassignment of the ccTLD manager
(i.e. an administrative "redelegation", rather than a technical
redelegation). ICANN is not granted the power to exercise discretion on
fulfilling change requests based on a ccTLD's non-compliance with a zone
transfer requirement.

Furthermore, ICANN is not required in their Memorandum of Understanding
with the US Government, to conduct technical monitoring of other countries.
It is our firm belief that the responsibility for country codes rests
within the country itself.


3. Conclusion
=============

In our original questions to ICANN, we sought a list of the specific tests
conducted by IANA on the zone file. In response, ICANN has identified two
tests that could be conducted on zone files, but has not provided a
specific concrete operating procedure on how zone files are analysed and
remedied under this policy.

Based on what we have learned from the FAQ, there is no convincing case for
the requirement of zone transfers. The technical arguments given do not
hold up to scrutiny, and the questionable impact of non-compliance does not
represent a serious threat to Internet stability.

There are important tests IANA should carry out, such as ensuring that
their delegations in the root zone match the authoritative name server
records in a TLD zone. However, such tests do not require zone transfer
access. Even with this fundamental test open for IANA to monitor at any
time, brief analysis shows many instances of mismatched data. Indeed, as
many as half of the ccTLDs tested recently had problems of this nature.

Fundamentally, ccTLD Managers have a duty of care in administering the data
they hold. This responsibility involves complying with local laws, and
ensuring suitable agreements are in place so that when data is shared it is
used in a responsible and accountable way.

ICANN's demand of providing them unqualified access to the zone file,
without any contract, and without open, established and publicly agreed
policies on exactly how that data may be used, would represent a clear
failure by ccTLDs in their fiduciary duty.

IANA does have a role to play in ensuring that services under their purview
are working correctly, and that delegations are handed off correctly.
However, they are not guardians of the Internet, and each subsequent level
in the DNS must take primary responsibility for how their zones are
operated.





--
 Kim Davies - Technical Policy Officer
 Council of European National TLD Registries
 direct: +43 662 872563 12; main: +44 1865 332400
 www.centr.org

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html