draft-ietf-dnsop-ohta-shared-root-server-00.txt   draft-ietf-dnsop-ohta-shared-root-server-01.txt 
INTERNET DRAFT M. Ohta INTERNET DRAFT M. Ohta
draft-ietf-dnsop-ohta-shared-root-server-00.txt draft-ietf-dnsop-ohta-shared-root-server-01.txt
Tokyo Institute of Technology Tokyo Institute of Technology
July 2000 July 2001
Root Name Servers with Inter Domain Anycast Addresses Root Name Servers with Inter Domain Anycast Addresses
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
Abstract Abstract
This memo describes an operational guideline for root name servers to This memo describes an operational guideline for root name servers to
share unicast (interdomain anycast) addresses. share unicast (interdomain anycast) addresses.
1. Motivation 1. Motivation
DNS root servers are the essential component of the Internet that all DNS root servers are the essential component of the Internet that all
the ISPs in the world want to run several root servers. the ISPs in the world want to run several root servers.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
So, even with anycast addresses, there should be multiple root So, even with anycast addresses, there should be multiple root
servers. servers.
However, as anycast solves the problem of load concentration, we However, as anycast solves the problem of load concentration, we
don't need so many anycast IP addresses, don't need so many anycast IP addresses,
We should have at least 3 and at most 7 anycast addresses for root We should have at least 3 and at most 7 anycast addresses for root
servers. servers.
4. Security Considerations 4. Ongoing Experiment
An experiment is ongoing with a block of IP addresses 192.83.230/24
in AS 4128 and DNS servers sharing an IP address of 192.83.230.1.
Domains served by the DNS servers are not root domain but are: real-
internet.org. and psg.com.
If one is interested in joining (or just watching) the test, send a
mail containing a single line of:
subscribe aroot
to
majordomo@ops.ietf.org
the mailing list is located at:
aroot@ops.ietf.org
Archive of the list is available at
ftp://ops.ietf.org:/pub/lists/aroot.
If there is something wrong with route information from AS 4128, the
author of the memo or the mailing list for the test may be contacted.
However, for direct contact to the source of the problem, the contact
person of an AS next to AS 4128 in the AS path of problematic route
information should be contacted.
5. Security Considerations
This memo describes just an operational guideline with no protocol This memo describes just an operational guideline with no protocol
change. As such, the guideline does not introduce any security issues change. As such, the guideline does not introduce any security issues
of the protocol level. of the protocol level.
As the route forgery to the root servers can be implemented today As the route forgery to the root servers can be implemented today
without this memo by anyone including local intruders, the guideline without this memo by anyone including local intruders, the guideline
does not introduce any security issues of the operational level, does not introduce any security issues of the operational level,
either. either.
A guideline to track down and verify valid or forged route or AS path A guideline to track down and verify valid or forged route or AS path
to the root servers is described in section 2. to the root servers is described in section 2.
5. Author's Address 6. Author's Address
Masataka Ohta Masataka Ohta
Computer Center Graduate School of Information Science and Engineering
Tokyo Institute of Technology Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku 2-12-1, O-okayama, Meguro-ku
Tokyo 152-8550, JAPAN Tokyo 152-8552, JAPAN
Phone: +81-3-5734-3299 Phone: +81-3-5734-3299
Fax: +81-3-5734-3415 Fax: +81-3-5734-3299
EMail: mohta@necom830.hpcl.titech.ac.jp EMail: mohta@necom830.hpcl.titech.ac.jp
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/