Re: against broken tld content

[bmanning@karoshi.com]

 please define the term "broken" 
 


> 
> Any comment?
> 
> 					Masataka Ohta
> ---
> 
> 
> 
> 
> 
> 
> INTERNET DRAFT                                                   M. Ohta
> draft-ohta-broken-tld--1.txt               Tokyo Institute of Technology
>                                                           September 2003
> 
>                  Distributed Actions Against Broken TLD
> 
> Status of this Memo
> 
>    This document is an Internet-Draft and is subject to all provisions
>    of Section 10 of RFC2026.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet- Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/1id-abstracts.html The list of Internet-Draft
>    Shadow Directories can be accessed at http://www.ietf.org/shadow.html
> 
> Abstract
> 
>    This memo describes actions against broken content of a primary
>    server of a TLD.  Without waiting for an action of some, if any,
>    central authority, distributed actions TLD server operators and ISPs
>    can settle the issue, for a short term.
> 
> 1. Introduction
> 
>    DNS is a fully distributed database of domain names and their
>    associated values with loose integrity.
> 
>    However, the primary server of a zone is a single point of failure of
>    the zone to hold the current most copy of the zone and such a failure
>    at TLD can cause a lot of damage to the Internet.
> 
>    As it may take time for a central authority, if any, take care of the
>    problem, this memo describes distriburted actions as a short term
>    solution to protect the Internet against broken TLD zone content.
> 
>    The long term solution is to let the primary server operator fix the
>    content or to change the primary server operator, which may involve a
>    central authority.
> 
> 
> 
> M. Ohta                Expires on March 17, 2004                [Page 1]
> 
> INTERNET DRAFT                 Broken TLD                      June 2003
> 
> 
>    Similar technique is applicable to root servers with broken contents.
> 
> 2. Actions of TLD Server Operators
> 
>    A TLD server operator who have found that TLD zone content is broken
>    should disable zone transfer and use a copy of old zone content known
>    not to be broken.
> 
>    Or, if the fix for the zone content is obvious and easy, the operator
>    may manually or automatically edit the content of the current most
>    one without updating SOA serial number. In this case, zone transfer
>    may not be disabled, though actions of ISPs described in section 3
>    may make the transfer from servers of broken content impossible.
> 
> 3. Actions of ISPs
> 
>    ISPs should disable routes to TLD servers with broken content and/or
>    filter packets to/from the TLD servers.
> 
>    ISPs should periodically check the servers, whether they still
>    contain broken content or not.
> 
> 4. Security Considerations
> 
>    As for security, TLD servers should never have broken content.
> 
> 5. Author's Address
> 
>    Masataka Ohta
>    Graduate School of Information Science and Engineering
>    Tokyo Institute of Technology
>    2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN
> 
>    Phone: +81-3-5734-3299
>    Fax: +81-3-5734-3299
>    EMail: mohta@necom830.hpcl.titech.ac.jp
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> M. Ohta                Expires on March 17, 2004                [Page 2]
> 
> #----------------------------------------------------------------------
> # To unsubscribe, send a message to <dnsop-request@cafax.se>.
> 

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.