<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: Re: [ga] Re: ICANN & Stability
However it is nice that the father of the Internet, the President of the US
Government International Agency for the Internet and the Germany NIC
President relate on this mailing list, I find very sad the reasons why the
USG root information is no more maintained acurately. BTW this now makes
the open roots the authoritative source about legacy TLD entries.
A network is a system for everyone to relate together, it is very sad that
it is today a system for people in charge of the Internet network stability
to oppose. We - the users - do not want a new Network split.
I therefore submit the following motion to the GA
"
ICANN is requested to make sure that nameservers IP address changes are
reflected in the shortest delays (ie less than 36 hours) in the USG root
servers system master file.
ICANN is requested to keep informed the Internet Global Community if it
becomes temporarily unable to maintain that minimum level of quality of
service.
ICANN is requested to present in the shortest delays a secure scheme
permitting the IP address changes decided by the TLD Managers to be
incporated into the USG root file in less than 48 hours after recieving the
TLD Mamager information.
"
jfc
On 19:46 24/09/02, Sabine Dolderer/Denic said:
>Dear Stuart,
>Dear Vint,
>
>(-> cc Elisabeth can you please forward my mail to the NC)
>
>
>On 22.09.2002 05:26 "M. Stuart Lynn" <lynn@icann.org> wrote:
> >
> > 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.
>
>you should also mention that there are views validating the format of
>zonefiles has no technical value, is not needed and can therefore be
>skiped.
>
> >
> > 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.
>
>Technical stability of DNS relys much more on the realtime performance of
>the related server and a timly and redundant answering from different
>places in the Internet. These things have nothing to do with zonefile
>information but with long term monitoring and underlying network
>infrastructure. But even this is in my opinion up to the operator of a TLD
>and his community.
>
> >
> > 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 only database which IANA has to maintain is the database who operates
>which TLD and what are the related nmameservers. For DE this information is
>DENIC and a set of nameservers. To check the operational status of our
>nameservers before entering them in the IANA database you simply has to ask
>them if they felt authorativ for .de (dig @dns.denic.de .de). I am not
>aware of other databases which IANA maintain and which they have to check
>for 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.
>
>If a ccTLD manager wants to optain additional service from IANA like
>assistance in error checking then it has to be discussed and can be done as
>long as it didn't took too much ressources. For professional assistance
>these kind of consultancy services should be left to others like Men &
>Mice or others who offer these kind of services on a professional
>commercial base.
>
> >
> > 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.
>
>As Men & Mice is a commercial company offering DNS configuration assistance
>I am sure that they will welcome your support for their service ;-).
>
> > 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.
>
>I am sure that you have also learned from that survey that the .DE-zone is
>quit healthy and thats why we are doing some checks similar to those I
>discribed above. But we are doing this without checking the zonefile as
>this - as I pointed out earlier - not needed for the check of 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.
>
>I am not really convinced. Usually one tries to have a balance between the
>benefits and the costs of something. Currently a gTLD-level and a lot of
>ccTLDs there are no checks at all when a domain is inserted in the TLD.
>DENIC does at least check our delegated domains for nameserver consitency
>but we didn't check if siemens.de or ibm.de are doing this also. I have
>some understanding that IANA does also check nameserver consistency at
>their level and I would recommend to siemens.de and ibm.de to do that also.
>But I don't think it's DENIC's task to enforce this within siemens.de and
>ibm.de and I don't think it's IANA's to do so for .de.
>
> >
> > Although with cooperation from the TLD managers (which has historically
> > been quite high)
>
>Historically the DNS software was unable to supress unsolicited
>zonetransfers and the TLD managers were not asked (at least not between
>1994 and now, when I am operating it). You shouldn't interpret this a
>cooperation.
>
> > 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.
>
>As you have no access to our database it is unclear to me how you want to
>perform checks if the zonefile we produce is reflecting our database
>correct.
>
> > 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>
>
>I think you should also point out in your summary that also while some
>(Stuart) suggested to performe these checks periodically. Some (CENTR,
>LACTLD, ccTLD constituency at their meeting in Bucharest, and others on the
>lists) suggest to stop checking the zones immediately.
>
> >
> > 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.
>
>One big step to improve DNS data quality is to proceed changes in the root
>much more timely.
>
> >
> > 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.
>
>As this issue is very important for ccTLDs I would also recommend not to
>decide things without their support.
>
>
>Sabine
>
> >
> > 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-02s
> ep02.
>
> > >> >
> > >> >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@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
> >
> >
>--
>Sabine Dolderer
>DENIC eG
>Wiesenhüttenplatz 26
>D-60329 Frankfurt
>
>eMail: Sabine.Dolderer@denic.de
>Fon: +49 69 27235 0
>Fax: +49 69 27235 235
>
>
>--
>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
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.386 / Virus Database: 218 - Release Date: 09/09/02
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|