ICANN/GNSO
DNSO and GNSO Mailling lists archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

[council] Practices Concerning Review of TLD Zone Files


I am sending this note to you on behalf of Vint Cerf and myself. Stuart
______________________________________________

Dear Names Council:

Over the past few weeks, questions have arisen regarding the IANA
practice of obtaining and reviewing TLD zone files at the time of
changes in the nameservers listed for the TLD in the root zone. The
various points of view expressed suggest to us that it would be
productive to re-examine the objectives for this practice and to
consider alternative means by which those objectives might be reached.
The principal motivation for this practice has been to improve the
quality of the DNS service by validating the format of the
TLD zone files to ensure correct configuration.

Considering that this examination has until now tended to be done by
the IANA only when a TLD nameserver is being transferred to a new
operating site, we believe it is appropriate to ask the Committee on
Security and Stability (SAC) to look into the matter and to develop a
longer-term recommendation as to what would be the most sound technical
practices to follow to promote better DNS stability; and to provide an
interim recommendation while the broader issues are being explored.
Since this, however, involves domain names, we would want to enquire
whether the DNSO concurs with this approach before asking the SAC to
undertake this analysis.

Historically, the goal of the practice has been to improve the
quality of data in the DNS.  Pursuing the RFC 1591 policy that the
IANA should make checks to verify nameserver "operational status and
database accuracy", the IANA follows the practice of obtaining
and technically reviewing TLD zone files as part of the technical checks
it performs when nameserver changes are requested. Although checks for
the most severe database misconfigurations can be performed by other
means, many less severe errors have been detected through this review.
The ordinary result of finding one or more of these less severe errors
is to proceed with the root-zone change, to alert the ccTLD manager of
the error, and to request that it be remedied.

DNS data accuracy continues to be an important, and by some measures
increasingly urgent, goal.  Recent "Domain Health" surveys conducted
by Men & Mice <http://menandmice.com/6000/6350_eu_survey.html> and
<http://menandmice.com/6000/61_recent_survey.html> have reported
surprisingly high performance error rates in reviews of subdomains
within various TLDs.  While DNS quality at the TLD level appears to
be much better, discussions at the November 2001 ICANN security
meeting and the Domain Health surveys have demonstrated that it is
important that the community work continuously to maintain and improve
DNS quality.  Particularly with increasing requirements from the broader
society for security and trustworthiness within the DNS, it is important
for the ICANN community to develop and implement practices that promote
high-quality DNS data at all levels, and with a higher frequency than
only at times when nameserver changes are contemplated.

Although with cooperation from the TLD managers (which has historically
been quite high) the current IANA practice has served to locate and
allow correction of many DNS errors, recently four TLD managers have
denied the IANA download access to the zone files for their TLDs.
Without having the zone files, there is no reasonably practical method
for a third party to perform some checks of database accuracy.  This
disagreement has resulted in an unfortunate standoff situation that,
perversely, frustrates attempts to locate and correct TLD configuration
errors, and at the same time potentially introduces additional DNS data
errors through configuration mismatches between the DNS data in the root
zone (which remains unchanged) and the affected TLD zones (assuming the
TLD manager proceeds to change the TLD zone).

This debate has prompted some very helpful initial ideas from the
community regarding possible changes in practices that might be better
suited to achieve the goal of improved DNS data accuracy.  As pointed
out by Thomas Roessler
<http://www.dnso.org/clubpublic/ga/Arc11/msg00206.html>, the current
timing of technical checks may not be optimally suited to the goal
of improving DNS data quality.  As one of us (Stuart) has pointed
out, a strong argument can be made that TLD integrity checks would
be more effective, and the process for making root-zone updates
streamlined, by developing a possibly distributed and delegated process
for performing TLD zone-file reviews on a periodic basis
rather than as part of technical checks performed at the time of
nameserver changes.
<http://www.dnso.org/clubpublic/ga/Arc11/msg00210.html>

It appears to us that the issues about what practices should be
followed by the IANA, TLD managers, and other participants in the
ICANN process to promote improved DNS data quality is one that is ripe
for examination.  We believe that technical focus of these issues
makes it appropriate to have at least the initial examination and
analysis conducted by the ICANN Security and Stability Advisory
Committee.

Because the issues also concern domain names (the focus of the DNSO),
however, we would like feedback about whether the Names Council believes
for any reason that it is inappropriate that they be referred to the
Security and Stability Advisory Committee.  Because an early resolution
of these issues would be helpful to all concerned, we would appreciate
your considering the appropriateness of the referral at your earliest
convenience.

Our mutual interest is to take the opportunity occasioned by these
discussions to encourage the development of more effective methods for
improving DNS data quality at all levels in the system.

Regards,

Vint Cerf
Chairman

Stuart Lynn
President and CEO
-- 

__________________
Stuart Lynn
President and CEO
ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
Tel: 310-823-9358
Fax: 310-823-8649
Email: lynn@icann.org



<<< Chronological Index >>>    <<< Thread Index >>>