Re: [ga] Fwd: LACTLD comments on Zone Transfers

[Jonathan Weinberg <weinberg@mail.msen.com>]

	I'm impressed by the degree to which everyone has managed to avoid
talking about the elephant under the bed here.  As the LACTLD message
below states, and as Karl's message at
<http://www.dnso.org/clubpublic/ga/Arc11/msg00268.html> explains in
detail, the ICANN position that it needs zone file access "for purposes of
verifying and ensuring DNS operational stability and performance" seems
problematic.  On the other hand, I'd guess that zone file access would
simplify ICANN's task if it chose to redelegate a ccTLD away from an
operator unhappy with that change.  Anyone want to talk about this
explicitly?

Jon


Jon Weinberg
weinbergmsen.com


On Thu, 19 Sep 2002, Alexander Svensson wrote:
> 
> This has been forwarded by Oscar Robles to the Names Council list:
> (http://www.dnso.org/clubpublic/council/Arc11/msg00045.html)
> 
> >To: root-mgmt@iana.org, cctld-adcom@wwtld.org, cctld-discuss@wwtld.org
> >Subject: [cctld-discuss] LACTLD comments on Zone Transfers
> >Date: Thu, 19 Sep 2002 07:55:35 -0600
> >
> >Hello all:
> >
> >For your information:
> >
> >----------------------------------------------------------------------
> >Comments of LACTLD on zone transfers
> >---------------------------------------------------------------------
> >
> >As a result of several questions raised by the ccTLDs to ICANN
> >(IANA) about the reasons to require zone file transfer to IANA, and
> >the process they follow to review that information, ICANN issued
> >recently a FAQ http://www.iana.org/faqs/tld-zone-access-faq.htm
> >
> >After reviewing this FAQ, we find the explanation provided by
> >ICANN to be unconvincing. If these are the reasons why IANA has
> >refused to update the name server configuration of ccTLDs that
> >required urgent changes, changes that were needed to avoid
> >possible chaos caused by the sudden bankrupcy of a major ISP, we
> >believe that, in doing so, IANA may have been risking endangering
> >the very operational stability of the Internet it is charged to
> >preserve.
> >
> >We cannot deny that during the emergency created by the failure of
> >KPNQuest, IANA personnel worked very hard to process the
> >changes for many ccTLDs, but we also believe that their good work
> >has been hampered by an unreasonable policy that has not allowed
> >them to perform the changes for all the ccTLDs that required them.
> >The fact that ns.eu.net is still operating has helped avoid a crisis,
> >but this is in spite of the policy in question, not thanks to it.
> >
> >We believe that the tests that IANA needs to perform to ensure the
> >DNS operational stability and performance may be done without
> >the requirement of zone file transfers. The two examples provided
> >to illustrate why zone transfer would be required, namely to check
> >that two independent name servers be provided for the sub-
> >domains of a TLD and to check for proper format, do not survive
> >close examination. We do agree that it is IANA's job to check that
> >each TLD has two independent functional DNS servers (which can
> >be tested without zone access), but we think that IANA going
> >routinely deeper down the tree goes against the principle of
> >delegation of authority on which the DNS is based. Furthermore,
> >current technology makes it possible that many servers be
> >operating using a single IP address, through the use of anycast. As
> >far as checking that the zone file follows the proper format, we think
> >this is not necessary nor sufficient, as some versions of BIND are
> >not RFC 1034 compliant.
> >
> >We also remain unconvinced of the need for IANA to have a copy
> >of the zone file to allow the operation of the TLD in case of
> >catastrophic failure. In case of a disaster, the TLD should have
> >proper recovery mechanisms, because their operation is not limited
> >to a single DNS server, but involves a much more complex IT
> >infrastrucure which is needed to maintain the DNS operation.
> >ICANN could not do anything more with the zone file than to
> >preserve for a few hours an operation that is needed for many days
> >in the event of a disaster and total loss of information. We firmly
> >believe in the need to have a robust infraestructure and procedures
> >in place to minimize the probability of this kind of failure, and to
> >have sound contingency plans available, but the IANA policy might
> >even work against this, by generating a false sense of security.
> >
> >Since ICANN is yet to provide a reasonable explanation for the
> >requirement to open the zone files for transfer to IANA, we
> >understand very well the position of those ccTLD administrators
> >that have decided not to allow such transfers. It is quite possible
> >that allowing this transfers might create a security hole. Even if
> >transmission could be done in a completely secure way, it would be
> >very hard for ICANN to provide a guarantee that the storage of the
> >zone files in its servers would not be vulnerable to the frequent
> >attacks that those servers suffer.
> >
> >Given that RFC 1591 does not explicitly require that zone files be
> >available to IANA, and given that, until recently (two years after it
> >appeared in ICP-1) IANA had not enforced this rule, we believe that
> >this requirement should be eliminated. We are not against some
> >ccTLD administrators making their zone files voluntarily available
> >to IANA --in fact some of us do allow such access-- but we strongly
> >reject IANA's policy of delaying urgent technical updates until it
> >gets access to the zone file.
> >
> >It would be possible to argue endlessly about whether ICP-1 is valid
> >ICANN policy or not, given that it did not go through the proper
> >policy development process and that it appears that the Board only
> >approved its number, and not its substance. However, we think that
> >this is a matter of the greatest urgency and that it cannot wait for
> >such a discussion to be settled. There is no rule anywhere that says
> >that IANA is forbidden to process changes of TLD name servers
> >unless the zone file is available to it, and we call therefore to IANA
> >to stop demanding these transfers as a precondition to make these
> >changes. Such a step would go a long way towards showing that
> >IANA and the ccTLDs are able to work together to achieve the goal
> >of Internet stability that we all share.
> >
> >LACTLD
> >
> >-----------------------------
> >Rafael (Lito) Ibarra
> >UCA JoseŽ SimeoŽn Can~as
> >San Salvador, El Salvador (SV)
> >Tel +(503) 210-6600, ext. 270, 271
> >Fax +(503) 210-6640
> 
> --
> 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
> 


Jonathan Weinberg
weinberg@msen.com

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