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