Re: [ga] CENTR Reaction to IANA Zone Access FAQ

[Marc Schneiders <marc@fuchsia.bijt.net>]

On Thu, 26 Sep 2002, at 18:05 [=GMT+0200], Kim Davies wrote:

> These two examples are: checking that domains delegated under the ccTLD
> have at least two name servers,

> 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 requirement was moreover given up in com/net/org years ago. Have the
ccTLDs to bow deeper than the gTLDs for ICANN?

And why is it, that ICANN tries to control those they have no power over,
in matters that are unimportant, while they leave those that they can
control, with whom they have contracts, in serious issues, do it their
way? ICANN is more strict for the ccTLDs (that behave well) than for the
registries and registrars in the gTLDs, where some scandal or scam is
reported each week.

Is it all about _getting_ power?

> 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
>

--
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