Subject: Re: against broken tld content

From: Masataka Ohta <[email-masked]>
Date: Tue, 23 Sep 2003 02:25:10 +0859 ()

Below is a revised draft ID with the following changes.

1) "Content" is added to title.

	Distributed Actions Against Broken TLD Content

2) some text added to "1. Introduction".

< the problem, this memo describes distriburted actions as a short
< term solution to protect the Internet against broken TLD zone content.
---
> the problem, this memo describes distributed actions as a short
> term solution to protect the Internet against broken TLD zone content
> and the damage caused by it.

3) some text added to "3. Actions of ISPs".

> If such action considerably reduces the number of available TLD servers,
> ISPs may operate their own servers overriding the IP addresses
> of formal TLD servers.
> Such overriding servers should have
> a copy of old zone content known not to be broken.
> Or, if the fix for the zone content is obvious and easy, the
> overriding servers may act as semi transparent proxies to
> formal servers (routing tricks necessary as IP addresses of
> the proxies and the formal servers are identical) modifying only
> the broken part.
> Considering that NAT-based network providers,
> which provide limited service such as web and e-mail with semi
> transparent DNS proxies, are often called ISP, it is fine
> for ISPs to use DNS proxies, especially when it improves web
> and/or e-mail environment of their customers. However, advance negotiation
> should be made, if the override affects other ISPs.

Any further comment?

						Masataka Ohta

--

INTERNET DRAFT                                                   M. Ohta
draft-ohta-broken-tld--1.txt               Tokyo Institute of Technology
                                                          September 2003

             Distributed Actions Against Broken TLD Content

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 distributed actions as a short term
   solution to protect the Internet against broken TLD zone content and
   the damage caused by it.

   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

M. Ohta                Expires on March 22, 2004                [Page 1]

INTERNET DRAFT                 Broken TLD                      June 2003

   central authority.

   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.

   If such action considerably reduces the number of available TLD
   servers, ISPs may operate their own servers overriding the IP
   addresses of formal TLD servers.  Such overriding servers should have
   a copy of old zone content known not to be broken.  Or, if the fix
   for the zone content is obvious and easy, the overriding servers may
   act as semi transparent proxies to formal servers (routing tricks
   necessary as IP addresses of the proxies and the formal servers are
   identical) modifying only the broken part.  Considering that NAT-
   based network providers, which provide limited service such as web
   and e-mail with semi transparent DNS proxies, are often called ISP,
   it is fine for ISPs to use DNS proxies, especially when it improves
   web and/or e-mail environment of their customers. However, advance
   negotiation should be made, if the override affects other ISPs.

   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

M. Ohta                Expires on March 22, 2004                [Page 2]

INTERNET DRAFT                 Broken TLD                      June 2003

   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3299
   EMail: [email-masked]

M. Ohta                Expires on March 22, 2004                [Page 3]

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 23 Sep 2003 08:54:33 +0200 (CEST)

> > a copy of old zone content known not to be broken.

You are still making the assumption that a given TLD is being operated on
its own set of nameservers.  What is the suggested behaviour for ISPs
where one nameserver hosts a _lot_ of TLDs, and just one TLD has 'broken'
content?

In the not-so-hypothetical case of ns.ripe.net, I suspect that the other
98 TLDs hosted on there would be a tad annoyed at ISP's local over-riding
of their data, assuming that the ISPs could get a hold of the complete
data in the first place.

>    should disable zone transfer

This is ill-defined.  The TLD server operator should disable zone
transfers from being possible from its nameserver, or it should disable
its nameserver from making zone transfers ?

> and use a copy of old zone content known
>    not to be broken.

Sounds reasonable, although it still depends on the TLD server operator
making regular backups of the zone content that its server publishes.

>    may make the transfer from servers of broken content impossible.

I dislike the 'without updating' the SOA serial number.  It would be
better, IMHO, to have an intentional mismatch of SOA serial numbers
between the 'broken' versions and the 'corrected' versions.  Having
seemingly identical editions of the zone with varying behaviour about is a
headache when faultfinding.

( Actually I dislike the entire concept of editing the zone content,
  especially in cases where you are not the primary source of said
  content. )

-- 
                             Bruce Campbell           I speak for myself