Internet DRAFT - draft-catalone-rockell-hadns
draft-catalone-rockell-hadns
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:11:49 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 30 Jun 1999 13:50:00 GMT
ETag: "2e7f2b-18e6-377a2088"
Accept-Ranges: bytes
Content-Length: 6374
Connection: close
Content-Type: text/plain
Internet Engineering Task Force G. Catalone
Internet Draft R. Rockell
Document: draft-catalone-rockell-hadns-00.txt Sprint
Category: Informational June 1999
Implementation of a High Availability DNS System
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
DNS servers have long suffered from availability and reachability
issues. To that end, methods and techniques are developed to
maintain the availability and reachability of this essential
service.
This Internet-Draft discusses one way that multiple DNS servers can
share a common IP address and provide a high level of reachability
and reliability.
This technique may be useful in implementing other server
configurations.
Conventions used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
Catalone & Rockell Expires: December 1999 1
draft-ietf-catalone-hadns-00.txt June 1999
Overview
What we have done, at Sprint, is to assign the same IP address to
several DNS servers on our network. This technique, we believe, will
provide our customers with a highly available and reliable DNS
service, without regard to the customer or server location on our
network.
All the DNS servers advertise the same address via BGP. The routing
protocol itself decides which machine will be used at any given
point in the network.
In the event any particular DNS server becomes unavailable, that
server's routing information is withdrawn from the network by the
routing protocol and a new best route is chosen.
Similarly, as a previously unavailable server becomes available, its
routing information will be added to the network.
Server Setup
The DNS server is configured in a normal fashion. If the machine
hosting the DNS server does not provide native BGP service,
additional software will need to be installed.
The server will have its primary IP address and also a secondary.
The secondary IP address would be the common address for all the
servers in the DNS mesh.
An AS number SHOULD be assigned to the DNS mesh: either an unused AS
that the organization already has or a reserved AS [2]. It is
possible to use one's current Autonomous System Number for this
setup, but one must be wary of the following:
The servers must be added correctly to your iBGP mesh.
The routes must not violate backbone routing policies, and
therefore must be tagged for non-transit to other providers if
they are more specific than those that would normally traverse
a peering. It is recommended that the common IP address come
from an aggregatable block of address space that is sent to
eBGP peers.
One MAY also use a reserved Autonomous System ID here as well.
However, care must be taken to ensure that the reserved AS is
stripped to all eBGP peerings, and not leaked to the global Internet
BGP table.
The DNS server will announce its connected networks to its connected
router via BGP. These connected networks will essentially be its
primary LAN address and its secondary interface (common IP address).
Router Setup
Catalone & Rockell Expires: December 1999 2
draft-ietf-catalone-hadns-00.txt June 1999
The connected router is configured to see the DNS server as an
external BPG peer. The router announces a default route to the DNS
server. Please note this configuration may be different dependant
upon the choices made above (see section "Server Setup" for detail).
The router tags these incoming routes with community strings in such
a way to identify their origin when viewed in the routing table and
to prevent them from being advertised to other external peers.
Optionally, the router would need to be configured with appropriate
access-lists to enforce local routing policies.
Security Considerations
This Internet-Draft does not address any security considerations.
References
[1] Bradner, S., "The Internet Standards Process û Revision 3",
BCP 9, RFC 2026, October 1996
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[3] Hawkins & Bates, "Guidelines for Creation, Selection, and
Registration of an Autonomous System (AS)", RFC 1930, March
1996
Acknowledgments
The authors would like to thank Michael Stevenson for his role in
the design of this architecture and Abha Ahuja for her assistance in
deployment.
Authors' Addresses
Gregory S. Catalone Sr.
12502 Sunrise Valley Drive
VARESA0104
Reston, VA 20196
USA
Phone: +1 703 689 7910
Email: catalone@sprint.net
Robert J. Rockell II
12490 Sunrise Valley Drive
VARESB0213
Reston, VA 20196
USA
Phone: +1 703 689 6322
Email: rrockell@sprint.net
Catalone & Rockell Expires: December 1999 3
draft-ietf-catalone-hadns-00.txt June 1999
Copyright Statement
Copyright (C) The Internet Society 1999. All Rights Reserved.
Catalone & Rockell Expires: December 1999 4
