<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [ga] Re: ICANN & Stability
Dear Thomas:
Thank you for your note and your concern.
You may be aware of the note (appended) that Vint Cerf and I have
sent to the Names Council. We believe it is important to have a
considered technical review of this issue that takes all viewpoints
into consideration.
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
_______________
--
At 3:49 PM +0200 9/19/02, Thomas Keller wrote:
>This mail is being sent on behalf of the Technical Advisory Council of
>DENIC (TACD) which represents the .de registrar community.
>
>Dear Stuart,
>
>with dismay the TACD has noticed that the crucial and long awaited
>changes of the root name servers for the zone .de have not taken place to the
>current day. It even appears that the whole process has come to a stop due to
>misunderstandings between ICANN in fulfillment of its IANA functions and
>the Board of DENIC as well as other ccTLD registries.
>
>To judge about the reasons of the current misunderstanding is out of the
>scope of the TACD but the TACD strongly believes that a mere dispute can not
>be a reason for ICANN to deny a simple technical implementation for any ccTLD
>registry as long as this registry is acting in favor of the local internet
>community.
>
>Therefore the TACD would like to emphasize DENICs request to perform the
>necessary steps as soon as possible.
>
>Please note that not performing the requested changes is not only a
>severe political issue but also jeopardizes the german Internet related and
>Internet dependent industries. All internet business, not only in Germany, is
>built on a foundation of trust that all Internet services are
>reliable and dealt
>with in a highly responsible manner. For the DNS as one of these
>services, if not
>the most important one, not updating the root name servers is endangering this
>trust and might lead to cutbacks of Internet related business,
>impacting guiltless
>companies and employees. This is a situation which cannot be tolerated by
>TACD nor by the DENIC community which TACD represents.
>
>Out of the above mentioned reasons the TACD wants to urge ICANN to rethink its
>position on this issue and move their political playing field towards a ground
>where no uninvolved party may be harmed.
>
>Tom Keller on behalf of the Technical Advisory Council of DENIC
>
>-
>
>Thomas Keller
>
>Domain Services
>Schlund + Partner AG
>Erbprinzenstr. 4 - 12 Tel.
>+49-721-91374-534
>76133 Karlsruhe, Germany Fax
>+49-721-91374-215
>http://www.schlund.de tom@schlund.de
>
>
>
>
>Am 16.09.2002 schrieb M. Stuart Lynn:
>> You are assuming, Danny, that the assumptions that underlie
>> Elisabeth's proposed resolution are correct. They are not. Perhaps
>> you might be interested in the facts before forming your
>> "impressions".
>>
>> There is no threat to Internet stability. Soon after KPNQwest
>> announced its suspension of operations, RIPE NCC agreed to assume
>> operation of the ns.eu.net nameserver (which had formerly been
> > operated by KPNQwest), and has committed to continue that operation
> > for as long as necessary to migrate secondary nameservice to other
>> nameservers. That nameserver has been operating for quite some time
>> in a sound and stable manner. The IANA has given priority to
>> handling requests to migrate from the KPNQwest nameservers, and as it
>> happens 38 of the 41 requests that have been received to migrate
>> nameservice from ns.eu.net have been satisfactorily completed.
>> (Incidentally, 37 of the 38 ccTLDs that have been migrated have no
>> contractual relationship with ICANN.) There are several other ccTLDs
>> that have not yet requested to migrate, and the IANA is in the
>> process of suggesting that they move along to suitable substitute
>> nameservice as well. Three of the ccTLD requests for migration have
>> not yet been completed because the ccTLD operators have (despite
>> repeated requests) failed to cooperate in allowing the IANA to
>> perform technical checks as provided by longstanding IANA policy.
>> See the FAQs at <http://www.iana.org/faqs/tld-zone-access-faq.htm>
> > for a description that we recently posted summarizing for ccTLD
>> managers the policy, its longstanding basis (documented back to RFC
>> 1591 in March 1994), and the means by which those seeking to change
>> the policy should proceed.
>>
>> To reiterate, however, there no threat whatsoever to Internet
>> stability, since the ns.eu.net nameserver continues to function
>> perfectly.
>>
>> Stuart
>>
>>
>> At 4:05 PM -0400 9/16/02, DannyYounger@cs.com wrote:
>> >Stuart,
>> >
>> >Having read the text of Elisabeth Porteneuve's proposed resolution on name
>> >server updates (reprinted below), I can't help but get the impression that
>> >either ICANN/IANA staff is thoroughly incompetent or that you are engaged
>> >in
>> >the process of blackmailing the ccTLD community. It would seem to me that
>> >some discussion on this topic is warranted as the assertion has been made
>> >that ICANN itself has threatened the stability of the Internet (a subject
>> >that I presume you would take seriously). As the President and Chief
>> >Executive Officer of this Corporation, that ostensibly deems the stability
>> >of
>> >the Internet to be its highest priority, can you comment on why your staff
>> >has failed to process these updates?
>> >
>> >Best regards,
>> >Danny
>> >
>> >
>> >Whereas the ICANN Evolution and Reform Committee (ERC) has published
>> >its second implementation report,
>> >http://www.icann.org/committees/evol-reform/draft-mission-core-values-02sep02.
>> >
>> >htm
>> >
>> >Whereas the stability of the universal Internet has been part of
>> >permanent preoccupations since the White Paper document,
>> >http://www.icann.org/general/white-paper-05jun98.htm
>> >
>> >Whereas on 28 November 1998, both the USG and the ICANN committed
>> >to abide by the principle of Internet stability in the MoU,
>> >http://www.ntia.doc.gov/ntiahome/domainname/icann-memorandum.htm
>> >
>> >Whereas the ccTLD Managers has been awaiting since years
>> >for correct IANA ccTLD database services, as explicitly specified
>> >in the Amendment 2 to the MoU of 11 September 2000, requesting
>> >for "Documentation of IANA procedures for root zone editing,
>> >root zone generation, and root zone WHOIS service".
>> >
>> >Whereas the ccTLD IANA Service Requirements has been restated
>> >once more in Bucharest on 25 June 2002 and approved unanimously,
>> >http://www.dnso.org/constituency/cctld/ccTLDbucharest-communique.html
>> >
>> >Whereas the ERC reaffirms that "Preserve and enhance the operational
> > >stability, reliability, security, and global interoperability of
>> >the Internet" is on top of the list of ICANN Core's values,
>> >
>> >Whereas the global interoperability and stability of Internet depends
>> >on the TLD name servers,
>> >
>> >Whereas the recent bankruptcy of KPNQwest, providing secondary
>> >services to several ccTLD Registries requested for prompt actions
>> >on IANA side to update the name servers records as requested by
>> >the ccTLD Managers,
>> >
>> >Whereas there is widespread dissatisfaction of ccTLD Managers about
>> >the ICANN failing to its IANA Function duty, and several name servers
>> >updates pending since three months (since June 2002),
>> >
>> >The NC therefore resolves that:
>> >The stability of universal Internet is in danger and request
>> >ICANN to take immediate actions to update ccTLD name servers entries.
>> >
>> >http://www.dnso.org/clubpublic/council/Arc11/msg00035.html
>>
>>
>> --
>>
>> __________________
>> 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
>> --
>> 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
>>
>
>gruss
>
>tom
> O /
> /| o
> / \ \|/
> wenn ein kind eine blume pflueckt ist das schoen.
> wenn alle kinder eine blume pfluecken ist die wiese leer.
>
>
>
>Content-Type: application/pgp-signature
>Content-Disposition: inline
>
>Attachment converted: Macintosh HD:Untitled (????/----) (000738DB)
--
__________________
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
--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|