Re: Re: [ga] Re: ICANN & Stability

["Sabine Dolderer/Denic" <dolderer@denic.de>]

Dear Stuart,

On 17.09.2002 20:28 "M. Stuart Lynn" <lynn@icann.org> wrote:
>
> Thomas,
>
> Thanks for your questions. See responses below.  References to FAQs
> are to "Frequently Asked Questions on Access to TLD Zone Files" at
> <http://www.iana.org/faqs/tld-zone-access-faq.htm>.
>
> Stuart
>
> Thomas Roessler wrote:
> [snip]
> >Two questions:
> >
> >1. What particular circumstances surrounding a change in secondary
> >name servers make these checks so necessary that the change must be
> >held up until the checks have been performed?
> >
>
> One of ICANN's significant efforts (prompted by requests by many
> ccTLD operators) has been to improve the IANA function to make its
> operations more consistent and timely.

we are waiting since July 23rd for an update of the root zone this seems to
be not a really improvement in timely operation.


> Although resource limitations
> until 2001 resulted in the IANA making discretionary judgments on
> some occasions that the zone-file-accuracy check would be skipped,

it was actually not done as it was not done before 1999. And there is no
reason to do it.

> applying that kind of selectivity is not desirable since it can seem
> ad hoc and not policy-driven. Accordingly, database accuracy checks
> are now performed in all cases at the time of nameserver changes.
> FAQs 5-7 summarize the checks that are done, which the IANA typically
> completes the same day the zone file is made available.

I don't see a documentation of the checks you perform Q5 gives a very
generalized idea why it can be helpfull without substanciating it. A6 is
talking about problems of misconfigured nameservers for the rootserver. But
then the question should be Q6.new Do millions of misconfigured nameservers
cause problems at root- or tld-nameserver level. The answer is yes but we
have to solve it because it cannot be prohibited. And A7 is indeed showing
a check which can only be performed at zonelevel and that is if there is a
delegation to at least 2 nameservers. Currently I am not aware that having
only one or even no nameservers cause problems to the overall stability of
the Internet but if this is the case IANA should take an immediate action
to deconfigure .com, .net and .org as there are a substantive portions of
the delegations to not existing nameservers ;-).

>
> Your question hints at another important issue, which perhaps should
> give rise to a policy-development process in this area.  The IANA
> performs the zone file checks at the time of nameserver changes
> because that was the time at which the checks were done in the ISI
> era.

The checks where even not performed during the ISI era as pointed out in an
email from Josh Elliot (see below) to the cctld-discuss list it was a wish.
And this wish is understandable if you have performed such services in the
beginning of DNS technologie. In 1994 and 1995 when people started to use
DNS it was sometimes helpful to give them advice in how to correct their
configurations and I would be happy if IANA will provide that on a
voluntary basis to those who want that.

je> Q15 - IANA always required access to zone files upon delegation, and it
je> was our desire that ccTLDs keep the zones open continuously, but if
they
je> didn't, we DID NOT refuse nameserver changes or any other TLD update.
je>
je> As most of you know, this policy was never strictly enforced or stated
je> until the creation of ICP-1.  I believe the intention of ICP-1 was to
je> create greater stability among ccTLD operations and to also create a
je> closer relationship between IANA and ccTLD managers.  This backfired
for
je> numerous reasons, but primarily due to IANA's inability/unwillingness
to
je> communicate and work constructively with the ccTLD community during the
je> first 18 months of ICANN's stewardship of IANA.
je>
je> Q16 - Beginning in 1996, we did not strictly enforce any AXFR
je> requirement, especially with managers we knew and trusted.  Again, zone
je> file access was not a serious requirement, and the IANA's inability to
je> transition from a soft policy to a strict one has led us to this
current
je> crisis.  Furthermore, there was not a problem of dedicated IANA
je> resources during the 1999-2001 period under ICANN, but rather a desire
je> from IANA's perspective to maintain relatively fast TLD changes and
je> continue building good relationships with TLD managers.
je>

> FAQ 14 discusses the reasons for this.  It seems reasonable,
> however, that going to a system of periodic checks of TLD zone files,
> rather than checking at the time of nameserver changes, might be a
> better way to address the problems of DNS database accuracy and
> consistency.

I think checking TLD zone files is out of the scope of ICANN and as these
zones nowadays are usually generated automatically out of the TLD database
and no longer hand edited there is usually no error at all.

> As pointed out in FAQs 19 and 20, we should all be
> receptive to improving coordination methods, and an examination of
> whether there are better ways to accomplish the goal of a sound,
> properly configured DNS would be an appropriate topic of a
> policy-development process.

As a improper configured DNS doesn't violate anybody besides the TLD itself
there is no need of a global policy. These things are and should be dealt
with by the local communities.

>
> >2. Were there any actual threats to stability due to the fact that
> >IANA did not exercise its access to zone files from 1999-2001?
>
> First, let me clarify that the IANA did perform *some* TLD zone-file
> checks in 1999-2001.  For the reasons noted in FAQ 16, it did not do
> this routinely.  This situation has now been corrected.
>
> As to problems from the less-than-uniform checking in the period up
> to 2001, it is of course difficult to say what errors weren't caught
> because some checks were not done.  During that period, however,
> errors were caught in cases where checks were done, and the IANA's
> more recent checks of previously unchecked TLDs have revealed some
> errors (that might or not have been present when earlier checks were
> skipped).  Of course, the DNS is very resilient and inevitably has
> many errors at any given time.  What is useful is a constructive,
> problem-solving approach to minimize the number and severity of
> errors.


To keep intentionally wrong information in the root causes much more
critical problems. We should clearly identify the different
responsibilities of different organisations. Your responsibility is to keep
the root proper and running and our responsibility is to do this for .DE.
If we don't mix up these things, things can easily be solved.

Sabine

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