Browse Prior Art Database

Distributing Authoritative Name Servers via Shared Unicast Addresses (RFC3258)

IP.com Disclosure Number: IPCOM000007694D
Original Publication Date: 2002-Apr-01
Included in the Prior Art Database: 2002-Apr-16
Document File: 12 page(s) / 22K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

T. Hardie: AUTHOR

Abstract

This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 17% of the total text.

Network Working Group                                          T. Hardie

Request for Comments: 3258                                 Nominum, Inc.

Category: Informational                                       April 2002

  Distributing Authoritative Name Servers via Shared Unicast Addresses

Status of this Memo

   This memo provides information for the Internet community.  It does

   not specify an Internet standard of any kind.  Distribution of this

   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This memo describes a set of practices intended to enable an

   authoritative name server operator to provide access to a single

   named server in multiple locations.  The primary motivation for the

   development and deployment of these practices is to increase the

   distribution of Domain Name System (DNS) servers to previously

   under-served areas of the network topology and to reduce the latency

   for DNS  query responses in those areas.

1.  Introduction

   This memo describes a set of practices intended to enable an

   authoritative name server operator to provide access to a single

   named server in multiple locations.  The primary motivation for the

   development and deployment of these practices is to increase the

   distribution of DNS servers to previously under-served areas of the

   network topology and to reduce the latency for DNS query responses in

   those areas.  This document presumes a one-to-one mapping between

   named authoritative servers and administrative entities (operators).

   This document contains no guidelines or recommendations for caching

   name servers.  The shared unicast system described here is specific

   to IPv4; applicability to IPv6 is an area for further study.  It

   should also be noted that the system described here is related to

   that described in [ANYCAST], but it does not require dedicated

   address space, routing changes, or the other elements of a full

   anycast infrastructure which that document describes.

Hardie                       Informational                      [Page 1]

RFC 3258        Distributing Authoritative Name Servers       April 2002

2.  Architecture

2.1 Server Requirements

   Operators of authoritative name servers may wish to refer to

   [SECONDARY] and [ROOT] for general guidance on appropriate practice

   for authoritative name servers.  In addition to proper configuration

   as a standard authoritative name server, each of the hosts

   participating in a shared-unicast system should be configured with

   two network interfaces.  These interfaces may be either two physical

   interfaces or one physical interface mapped to two logical

   interfaces.  One of the network interfaces should use the IPv4 shared

   unicast address associated with the authoritative name server.  The

   other interface, referred to as the administrative interface below,

   should use a distinct IPv4 address specific to that host.  The host

   should respond to DNS queries only on the shared-unicast interface.

   In order to provide the most consistent set of responses from the

   mesh of anycast hosts, it is good practice to limit responses on that

   interface to zones for which the host is authoritative.

2.2 Zone file delivery

...