Folks, I don't know if anyone here has seen this, but Ohta-san submitted this draft to IETF DNSOP a few days ago. Should we start discussing this here?
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Subject: Re: against broken tld content To: dnsop@cafax.se Date: Tue, 23 Sep 2003 02:25:10 +0859 () Sender: owner-dnsop@cafax.se
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: mohta@necom830.hpcl.titech.ac.jp
M. Ohta Expires on March 22, 2004 [Page 3]
#---------------------------------------------------------------------- # To unsubscribe, send a message to <dnsop-request@cafax.se>.
-- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)