<<<
Chronological Index
>>> <<<
Thread Index
>>>
[council] Fwd: Summary of CENTR document on FAQ zone access, lawyer to lawyer
Fyi.
================================================================
From: "Peter Dengate Thrush" <barrister@chambers.gen.nz>
To: "Jonathan Cohen" <jcohen@shapirocohen.com>
Cc: <ga@dnso.org>, <cctld-discuss@wwtld.org>
----- Original Message -----
From: "Jonathan Cohen" <jcohen@shapirocohen.com>
To: "Peter Dengate Thrush" <barrister@chambers.gen.nz>
Sent: Friday, September 27, 2002 7:41 AM
Subject: RE: on politics and trust
> Thanks,I WILL look into this seriously.
> Jonathan
>
I value this undertaking from you.
To assist, and in case you don't get it from elsewhere, I have pasted below
the response of organisation of Euorpean cc managers, Centr, on this topic.
There are further papers extant and being drafted, but this is the most
recent.
By way of summary for the board, the paper says that the change in policy:
1. contravenes the policy of delegation of authority, inherent in the DNS
2. uses obsolete procedures
3. involves ICANN in cctld data escrow
4. involves ICANN in a breach of data protection laws
5. would make registry managers liable for damage resulting from ICANN misuse
of data
6. exposes ICANN to local liability laws
7. is in breach of the contract with the USG to run IANA
8. is outside the scope of the MoU.
It also make the general point that its underlying assumption is a crossing
of the line of "coordination" to "responsibility"
In addition to checking the numbered issues above, I'd appreciate your
confirmation, and that of as many board members as will give it, of their
support for the redrafted Mission Statement from the ERC, visible at
http://www.icann.org/committees/evol-reform/draft-mission-core-values-02sep0
2.htm, and which confirms that ICANN's role is as a "coordinator": viz
"The mission of ICANN is to coordinate the stable and secure operation of
the Internet's unique identifier systems. In particular, ICANN:
a. Coordinates the allocation and assignment of three sets of unique
identifiers for the Internet; i.e.,
Domain names (forming a system referred to as "DNS"); "
The role of "coordinator" implicitly recognises that others have rights,
responsibilities and authority. A coordinator is not the superior, governor
or manager of these other entities, which in ICANN s case include cctld
managers, RIR's and root server operators - with none of whom ICANN has
reached a satisfactory relationship. I suggest its because the staff have
misunderstood the role of a coordinator, confusing it with a regulator, a
governor, a monopoly provider or a manager. I'd appreciate confirmation that
this is not a board error.
In reveiwing their position on this, it would also be valuable to the
community for the Board to endorse Core Value 3 in the Mission Statement.
In performing its mission, ICANN is to:
"3. To the extent feasible and appropriate, delegate coordination
functions to or recognize the policy role of other responsible
entities that reflect the interests of affected parties."
The issues of data privacy, escrow and cctld registry performance are issues
for the cctld registry manager, and the local internet community. Properly
recognised, many of them would be willing for an approved body to coordinate
those activities which would benefit the local and global internet
communities in being coordinated.
Icann needs to establish that it is the body trusted to be that coordinator,
and then to learn how to coordinate.
It is a role which many of us will support and assist with.
My regards
Peter
> -----Original Message-----
> From: Peter Dengate Thrush [mailto:barrister@chambers.gen.nz]
> Sent: Thursday, September 26, 2002 2:26 AM
> To: Jonathan Cohen; ga@dnso.org; cctld-discuss@wwtld.org;
> board@aptld.org
> Subject: Re: on politics and trust
>
>
> Hi Jonathan
> Thanks.
> I assume this relates to ICP-1, and the allegations of changes to policy
> without proper processes being followed.
> The questions are simple, really.
> 1. Many people have pointed out that ICP-1 involves a change of policy. The
> recent FAQ issued by the staff, one assumes without Board involvement,
> contains some further nonsense.
> This, despite the time it takes, is being dealt to by experts.
>
> 2. The board resolution only adopts the numbering system of ICP-1, not its
> contents.
>
> 3. The question for the Board to satisfy itself is: do the contents of ICP-1
> constitute new policy in any respect? Or, when they were first promulgated,
> did they?
>
snip
****************************************************************************
********
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
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|