Compare commits
1 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
efb1d6b0eb |
@@ -1,19 +0,0 @@
|
||||
|
||||
This Internet-Draft has been deleted. Unrevised documents placed in the
|
||||
Internet-Drafts directories have a maximum life of six months. After
|
||||
that time, they are deleted. This Internet-Draft was not published as
|
||||
an RFC.
|
||||
|
||||
Internet-Drafts are not an archival document series, and expired
|
||||
drafts, such as this one, are not available; please do not ask for
|
||||
copies... they are not available. The Secretariat does not have
|
||||
information as to future plans of the authors or working groups WRT the
|
||||
deleted Internet-Draft.
|
||||
|
||||
For more information or a copy of the document, contact the author directly.
|
||||
|
||||
Draft Author(s):
|
||||
|
||||
R. Hibbs: rbhibbs@pacbell.com
|
||||
|
||||
|
||||
@@ -1,408 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DNSEXT Working Group Brian Wellington
|
||||
INTERNET-DRAFT Olafur Gudmundsson
|
||||
<draft-ietf-dnsext-ad-is-secure-06.txt> June 2002
|
||||
|
||||
Updates: RFC 2535
|
||||
|
||||
Redefinition of DNS AD bit
|
||||
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document is an Internet-Draft and is in full conformance with
|
||||
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/ietf/1id-abstracts.txt
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html
|
||||
|
||||
Comments should be sent to the authors or the DNSEXT WG mailing list
|
||||
namedroppers@ops.ietf.org
|
||||
|
||||
This draft expires on December 25, 2002.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2002). All rights reserved.
|
||||
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
Based on implementation experience, the RFC2535 definition of the
|
||||
Authenticated Data (AD) bit in the DNS header is not useful. This
|
||||
draft changes the specification so that the AD bit is only set on
|
||||
answers where signatures have been cryptographically verified or the
|
||||
server is authoritative for the data and is allowed to set the bit by
|
||||
policy.
|
||||
|
||||
|
||||
|
||||
|
||||
Expires December 2002 [Page 1]
|
||||
|
||||
INTERNET-DRAFT AD bit set on secure answers June 2002
|
||||
|
||||
|
||||
1 - Introduction
|
||||
|
||||
Familiarity with the DNS system [RFC1035] and DNS security extensions
|
||||
[RFC2535] is helpful but not necessary.
|
||||
|
||||
As specified in RFC 2535 (section 6.1), the AD (Authenticated Data)
|
||||
bit indicates in a response that all data included in the answer and
|
||||
authority sections of the response have been authenticated by the
|
||||
server according to the policies of that server. This is not
|
||||
especially useful in practice, since a conformant server SHOULD never
|
||||
reply with data that failed its security policy.
|
||||
|
||||
This draft redefines the AD bit such that it is only set if all data
|
||||
in the response has been cryptographically verified or otherwise
|
||||
meets the server's local security policy. Thus, a response
|
||||
containing properly delegated insecure data will not have AD set, nor
|
||||
will a response from a server configured without DNSSEC keys. As
|
||||
before, data which failed to verify will not be returned. An
|
||||
application running on a host that has a trust relationship with the
|
||||
server performing the recursive query can now use the value of the AD
|
||||
bit to determine if the data is secure or not.
|
||||
|
||||
1.1 - Motivation
|
||||
|
||||
A full DNSSEC capable resolver called directly from an application
|
||||
can return to the application the security status of the RRsets in
|
||||
the answer. However, most applications use a limited stub resolver
|
||||
that relies on an external full resolver. The remote resolver can
|
||||
use the AD bit in a response to indicate the security status of the
|
||||
data in the answer, and the local resolver can pass this information
|
||||
to the application. The application in this context can be either a
|
||||
human using a DNS tool or a software application.
|
||||
|
||||
The AD bit SHOULD be used by the local resolver if and only if it has
|
||||
been explicitly configured to trust the remote resolver. The AD bit
|
||||
SHOULD be ignored when the remote resolver is not trusted.
|
||||
|
||||
An alternate solution would be to embed a full DNSSEC resolver into
|
||||
every application. This has several disadvantages.
|
||||
|
||||
- DNSSEC validation is both CPU and network intensive, and caching
|
||||
SHOULD be used whenever possible.
|
||||
|
||||
- DNSSEC requires non-trivial configuration - the root key must be
|
||||
configured, as well as keys for any "islands of security" that will
|
||||
exist until DNSSEC is fully deployed. The number of configuration
|
||||
points should be minimized.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires December 2002 [Page 2]
|
||||
|
||||
INTERNET-DRAFT AD bit set on secure answers June 2002
|
||||
|
||||
|
||||
1.2 - Requirements
|
||||
|
||||
The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD
|
||||
NOT", "RECOMMENDED", in this document are to be interpreted as
|
||||
described in RFC2119.
|
||||
|
||||
1.3 - Updated documents and sections
|
||||
|
||||
The definition of the AD bit in RFC2535, Section 6.1, is changed.
|
||||
|
||||
2 - Setting of AD bit
|
||||
|
||||
The presence of the CD (Checking Disabled) bit in a query does not
|
||||
affect the setting of the AD bit in the response. If the CD bit is
|
||||
set, the server will not perform checking, but SHOULD still set the
|
||||
AD bit if the data has already been cryptographically verified or
|
||||
complies with local policy. The AD bit MUST only be set if DNSSEC
|
||||
records have been requested via the OK bit [RFC3225] and relevant SIG
|
||||
records are returned.
|
||||
|
||||
2.1 - Setting of AD bit by recursive servers
|
||||
|
||||
Section 6.1 of RFC2535 says:
|
||||
|
||||
"The AD bit MUST NOT be set on a response unless all of the RRs in
|
||||
the answer and authority sections of the response are either
|
||||
Authenticated or Insecure."
|
||||
|
||||
The replacement text reads:
|
||||
|
||||
"The AD bit MUST NOT be set on a response unless all of the RRsets in
|
||||
the answer and authority sections of the response are Authenticated."
|
||||
|
||||
"The AD bit SHOULD be set if and only if all RRs in the answer
|
||||
section and any relevant negative response RRs in the authority
|
||||
section are Authenticated."
|
||||
|
||||
A recursive DNS server following this modified specification will
|
||||
only set the AD bit when it has cryptographically verified the data
|
||||
in the answer.
|
||||
|
||||
2.2 - Setting of AD bit by authoritative servers
|
||||
|
||||
A primary server for a secure zone MAY have the policy of treating
|
||||
authoritative secure zones as Authenticated. Secondary servers MAY
|
||||
have the same policy, but SHOULD NOT consider zone data Authenticated
|
||||
unless the zone was transferred securely and/or the data was
|
||||
verified. An authoritative server MUST only set the AD bit for
|
||||
authoritative answers from a secure zone if it has been explicitly
|
||||
configured to do so. The default for this behavior SHOULD be off.
|
||||
|
||||
|
||||
|
||||
Expires December 2002 [Page 3]
|
||||
|
||||
INTERNET-DRAFT AD bit set on secure answers June 2002
|
||||
|
||||
|
||||
2.2.1 - Justification for setting AD bit w/o verifying data
|
||||
|
||||
The setting of the AD bit by authoritative servers affects only a
|
||||
small set of resolvers that are configured to directly query and
|
||||
trust authoritative servers. This only affects servers that function
|
||||
as both recursive and authoritative. All recursive resolvers SHOULD
|
||||
ignore the AD bit.
|
||||
|
||||
The cost of verifying all signatures on load by an authoritative
|
||||
server can be high and increases the delay before it can begin
|
||||
answering queries. Verifying signatures at query time is also
|
||||
expensive and could lead to resolvers timing out on many queries
|
||||
after the server reloads zones.
|
||||
|
||||
Organizations that require that all DNS responses contain
|
||||
cryptographically verified data MUST separate the functions of
|
||||
authoritative and recursive servers, as authoritative servers are not
|
||||
required to validate local secure data.
|
||||
|
||||
3 - Interpretation of the AD bit
|
||||
|
||||
A response containing data marked Insecure in the answer or authority
|
||||
section MUST never have the AD bit set. In this case, the resolver
|
||||
SHOULD treat the data as Insecure whether or not SIG records are
|
||||
present.
|
||||
|
||||
A resolver MUST NOT blindly trust the AD bit unless it communicates
|
||||
with the full function resolver over a secure transport mechanism or
|
||||
using message authentication such as TSIG [RFC2845] or SIG(0)
|
||||
[RFC2931] and is explicitly configured to trust this resolver.
|
||||
|
||||
4 - Applicability statement
|
||||
|
||||
The AD bit is intended to allow the transmission of the indication
|
||||
that a resolver has verified the DNSSEC signatures accompanying the
|
||||
records in the Answer and Authority section. The AD bit MUST only be
|
||||
trusted when the end consumer of the DNS data has confidence that the
|
||||
intermediary resolver setting the AD bit is trustworthy. This can
|
||||
only be accomplished via out of band mechanism such as:
|
||||
|
||||
- Fiat: An organization can dictate that it is OK to trust certain DNS
|
||||
servers.
|
||||
- Personal: Because of a personal relationship or the reputation of a
|
||||
resolver operator, a DNS consumer can decide to trust that
|
||||
resolver.
|
||||
- Knowledge: If a resolver operator posts the configured policy of a
|
||||
resolver a consumer can decide that resolver is trustworthy.
|
||||
|
||||
In the absence of one or more of these factors AD bit from a resolver
|
||||
SHOULD NOT be trusted. For example, home users frequently depend on
|
||||
|
||||
|
||||
|
||||
Expires December 2002 [Page 4]
|
||||
|
||||
INTERNET-DRAFT AD bit set on secure answers June 2002
|
||||
|
||||
|
||||
their ISP to provide recursive DNS service; it is not advisable to
|
||||
trust these resolvers. A roaming/traveling host SHOULD not use DNS
|
||||
resolvers offered by DHCP when looking up information where security
|
||||
status matters.
|
||||
|
||||
When faced with a situation where there are no satisfactory recursive
|
||||
resolvers available, running one locally is RECOMMENDED. This has
|
||||
the advantage that it can be trusted, and the AD bit can still be
|
||||
used to allow applications to use stub resolvers.
|
||||
|
||||
|
||||
4 - Security Considerations:
|
||||
|
||||
This document redefines a bit in the DNS header. If a resolver
|
||||
trusts the value of the AD bit, it must be sure that the responder is
|
||||
using the updated definition, which is any DNS server/resolver
|
||||
supporting the OK bit[RFC3225].
|
||||
|
||||
Authoritative servers can be explicitly configured to set the AD bit
|
||||
on answers without doing cryptographic checks. This behavior MUST be
|
||||
off by default. The only affected resolvers are those that directly
|
||||
query and trust the authoritative server, and this functionality
|
||||
SHOULD only be used on servers that act both as authoritative servers
|
||||
and recursive resolver.
|
||||
|
||||
Resolvers (full or stub) that trust the AD bit on answers from a
|
||||
configured set of resolvers are DNSSEC security compliant.
|
||||
|
||||
|
||||
5 - IANA Considerations:
|
||||
|
||||
None.
|
||||
|
||||
6 - Internationalization Considerations:
|
||||
|
||||
None. This document does not change any textual data in any
|
||||
protocol.
|
||||
|
||||
7 - Acknowledgments:
|
||||
|
||||
The following people have provided input on this document: Robert
|
||||
Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark,
|
||||
Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen.
|
||||
|
||||
Normative References:
|
||||
|
||||
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
|
||||
Specification'', STD 13, RFC 1035, November 1987.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires December 2002 [Page 5]
|
||||
|
||||
INTERNET-DRAFT AD bit set on secure answers June 2002
|
||||
|
||||
|
||||
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
|
||||
2535, March 1999.
|
||||
|
||||
[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
|
||||
``Secret Key Transaction Authentication for DNS (TSIG)'', RFC
|
||||
2845, May 2000.
|
||||
|
||||
[RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures
|
||||
(SIG(0))'', RFC 2931, September 2000.
|
||||
|
||||
[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC
|
||||
3225, December 2001.
|
||||
|
||||
|
||||
|
||||
Authors Addresses
|
||||
|
||||
Brian Wellington Olafur Gudmundsson
|
||||
Nominum Inc.
|
||||
2385 Bay Road 3826 Legation Street, NW
|
||||
Redwood City, CA, 94063 Washington, DC, 20015
|
||||
USA USA
|
||||
<Brian.Wellington@nominum.com> <ogud@ogud.com>
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2002>. All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
|
||||
|
||||
|
||||
Expires December 2002 [Page 6]
|
||||
|
||||
INTERNET-DRAFT AD bit set on secure answers June 2002
|
||||
|
||||
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires December 2002 [Page 7]
|
||||
@@ -1,430 +0,0 @@
|
||||
|
||||
|
||||
|
||||
IETF DNSOPS working group T. Hardie
|
||||
Internet draft Nominum, Inc
|
||||
Category: Work-in-progress January, 2002
|
||||
|
||||
draft-ietf-dnsop-hardie-shared-root-server-07.txt
|
||||
|
||||
|
||||
Distributing Authoritative Name Servers via Shared Unicast Addresses
|
||||
|
||||
|
||||
|
||||
Status of this memo
|
||||
|
||||
This document is an Internet-Draft and is in full conformance with
|
||||
all provisions of Section 10 of RFC 2026.
|
||||
|
||||
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
|
||||
|
||||
To view the list Internet-Draft Shadow Directories, see
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society 1999. 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 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.
|
||||
|
||||
|
||||
1. Architecture
|
||||
|
||||
1.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.
|
||||
|
||||
|
||||
1.2 Zone file delivery
|
||||
|
||||
In order to minimize the risk of man-in-the-middle attacks, zone
|
||||
files should be delivered to the administrative interface of the
|
||||
servers participating in the mesh. Secure file transfer methods and
|
||||
strong authentication should be used for all transfers. If the hosts
|
||||
in the mesh make their zones available for zone transfer, the administrative
|
||||
interfaces should be used for those transfers as well, in order to avoid
|
||||
the problems with potential routing changes for TCP traffic
|
||||
noted in section 1.5 below.
|
||||
|
||||
1.3 Synchronization
|
||||
|
||||
Authoritative name servers may be loosely or tightly synchronized,
|
||||
depending on the practices set by the operating organization. As
|
||||
noted below in section 3.1.2, lack of synchronization among servers
|
||||
using the same shared unicast address could create problems for some
|
||||
users of this service. In order to minimize that risk, switch-overs
|
||||
from one data set to another data set should be coordinated as much
|
||||
as possible. The use of synchronized clocks on the participating
|
||||
hosts and set times for switch-overs provides a basic level of
|
||||
coordination. A more complete coordination process would involve:
|
||||
|
||||
a) receipt of zones at a distribution host
|
||||
b) confirmation of the integrity of zones received
|
||||
c) distribution of the zones to all of the servers in the
|
||||
mesh
|
||||
d) confirmation of the integrity of the zones at each server
|
||||
e) coordination of the switchover times for the servers in the
|
||||
mesh
|
||||
f) institution of a failure process to ensure that servers that
|
||||
did not receive correct data or could not switchover to the
|
||||
new data ceased to respond to incoming queries until the
|
||||
problem could be resolved.
|
||||
|
||||
Depending on the size of the mesh, the distribution host may also be
|
||||
a participant; for authoritative servers, it may also be the host on
|
||||
which zones are generated.
|
||||
|
||||
This document presumes that the usual DNS failover methods are the
|
||||
only ones used to ensure reachability of the data for clients. It
|
||||
does not advise that the routes be withdrawn in the case of failure;
|
||||
it advises instead the the DNS process shutdown so that servers on
|
||||
other addresses are queried. This recommendation reflects a choice
|
||||
between performance and operational complexity. While it would be
|
||||
possible to have some process withdraw the route for a specific
|
||||
server instance when it is not available, there is considerable
|
||||
operational complexity involved in ensuring that this occurs
|
||||
reliably. Given the existing DNS failover methods, the marginal
|
||||
improvement in performance will not be sufficient to justify
|
||||
the additional complexity for most uses.
|
||||
|
||||
|
||||
1.4 Server Placement
|
||||
|
||||
Though the geographic diversity of server placement helps reduce the
|
||||
effects of service disruptions due to local problems, it is
|
||||
diversity of placement in the network topology which is the driving
|
||||
force behind these distribution practices. Server placement should
|
||||
emphasize that diversity. Ideally, servers should be placed
|
||||
topologically near the points at which the operator exchanges routes
|
||||
and traffic with other networks.
|
||||
|
||||
1.5 Routing
|
||||
|
||||
The organization administering the mesh of servers sharing a unicast
|
||||
address must have an autonomous system number and speak BGP to its
|
||||
peers. To those peers, the organization announces a route to the
|
||||
network containing the shared-unicast address of the name server.
|
||||
The organization's border routers must then deliver the traffic
|
||||
destined for the name server to the nearest instantiation. Routing
|
||||
to the administrative interfaces for the servers can use the normal
|
||||
routing methods for the administering organization.
|
||||
|
||||
One potential problem with using shared unicast addresses is that
|
||||
routers forwarding traffic to them may have more than one available
|
||||
route, and those routes may, in fact, reach different instances of
|
||||
the shared unicast address. Applications like the DNS, whose
|
||||
communication typically consists of independent request-response
|
||||
messages each fitting in a single UDP packet presents no problem.
|
||||
Other applications, in which multiple packets must reach the same
|
||||
endpoint (e.g., TCP) may fail or present unworkable performance
|
||||
characteristics in some circumstances. Split-destination failures
|
||||
may occur when a router does per-packet (or round-robin) load
|
||||
sharing, a topology change occurs that changes the relative metrics
|
||||
of two paths to the same anycast destination, etc.
|
||||
|
||||
Four things mitigate the severity of this problem. The first is
|
||||
that UDP is a fairly high proportion of the query traffic to name
|
||||
servers. The second is that the aim of this proposal is to
|
||||
diversify topological placement; for most users, this means that the
|
||||
coordination of placement will ensure that new instances of a name
|
||||
server will be at a significantly different cost metric from
|
||||
existing instances. Some set of users may end up in the middle, but
|
||||
that should be relatively rare. The third is that per packet load
|
||||
sharing is only one of the possible load sharing mechanisms, and
|
||||
other mechanisms are increasing in popularity.
|
||||
|
||||
Lastly, in the case where the traffic is TCP, per packet load
|
||||
sharing is used, and equal cost routes to different instances of a
|
||||
name server are available, any DNS implementation which measures the
|
||||
performance of servers to select a preferred server will quickly
|
||||
prefer a server for which this problem does not occur. For the DNS
|
||||
failover mechanisms to reliably avoid this problem, however, those
|
||||
using shared unicast distribution mechanisms must take care that all
|
||||
of the servers for a specific zone are not participants in the same
|
||||
shared-unicast mesh. To guard even against the case where multiple
|
||||
meshes have a set of users affected by per packet load sharing along
|
||||
equal cost routes, organizations implementing these practices should
|
||||
always provide at least one authoritative server which is not a
|
||||
participant in any shared unicast mesh. Those deploying
|
||||
shared-unicast meshes should note that any specific host may become
|
||||
unreachable to a client should a server fail, a path fail, or the
|
||||
route to that host be withdrawn. These error conditions are,
|
||||
however, not specific to shared-unicast distributions, but would
|
||||
occur for standard unicast hosts.
|
||||
|
||||
Since ICMP response packets might go to a different member of the
|
||||
mesh than that sending a packet, packets sent with a shared unicast
|
||||
source address should also avoid using path MTU discovery.
|
||||
|
||||
Appendix A. contains an ASCII diagram of a example of a simple
|
||||
implementation of this system. In it, the odd numbered routers
|
||||
deliver traffic to the shared-unicast interface network and filter
|
||||
traffic from the administrative network; the even numbered routers
|
||||
deliver traffic to the administrative network and filter traffic
|
||||
from the shared-unicast network. These are depicted as separate
|
||||
routers for the ease this gives in explanation, but they could
|
||||
easily be separate interfaces on the same router. Similarly, a
|
||||
local NTP source is depicted for synchronization, but the level of
|
||||
synchronization needed would not require that source to be either
|
||||
local or a stratum one NTP server.
|
||||
|
||||
|
||||
2. Administration
|
||||
|
||||
2.1 Points of Contact
|
||||
|
||||
A single point of contact for reporting problems is crucial to the
|
||||
correct administration of this system. If an external user of the
|
||||
system needs to report a problem related to the service, there must
|
||||
be no ambiguity about whom to contact. If internal monitoring does
|
||||
not indicate a problem, the contact may, of course, need to work
|
||||
with the external user to identify which server generated the
|
||||
error.
|
||||
|
||||
|
||||
3. Security Considerations
|
||||
|
||||
As a core piece of Internet infrastructure, authoritative name
|
||||
servers are common targets of attack. The practices outlined here
|
||||
increase the risk of certain kinds of attack and reduce the risk of
|
||||
others.
|
||||
|
||||
3.1 Increased Risks
|
||||
|
||||
3.1.1 Increase in physical servers
|
||||
|
||||
The architecture outlined in this document increases the number of
|
||||
physical servers, which could increase the possibility that a
|
||||
server mis-configuration will occur which allows for a security
|
||||
breach. In general, the entity administering a mesh should ensure
|
||||
that patches and security mechanisms applied to a single member of
|
||||
the mesh are appropriate for and applied to all of the members of a
|
||||
mesh. "Genetic diversity" (code from different code bases) can be
|
||||
a useful security measure in avoiding attacks based on
|
||||
vulnerabilities in a specific code base; in order to ensure
|
||||
consistency of responses from a single named server, however, that
|
||||
diversity should be applied to different shared-unicast meshes or
|
||||
between a mesh and a related unicast authoritative server.
|
||||
|
||||
3.1.2 Data synchronization problems
|
||||
|
||||
The level of systemic synchronization described above should be
|
||||
augmented by synchronization of the data present at each of the
|
||||
servers. While the DNS itself is a loosely coupled system,
|
||||
debugging problems with data in specific zones would be far more
|
||||
difficult if two different servers sharing a single unicast address
|
||||
might return different responses to the same query. For example,
|
||||
if the data associated with www.example.com has changed and the
|
||||
administrators of the domain are testing for the changes at the
|
||||
example.com authoritative name servers, they should not need to
|
||||
check each instance of a named root server. The use of ntp to
|
||||
provide a synchronized time for switch-over eliminates some aspects
|
||||
of this problem, but mechanisms to handle failure during the
|
||||
switchover are required. In particular, a server which cannot make
|
||||
the switchover must not roll-back to a previous version; it must
|
||||
cease to respond to queries so that other servers are queried.
|
||||
|
||||
3.1.3 Distribution risks
|
||||
|
||||
If the mechanism used to distribute zone files among the servers is
|
||||
not well secured, a man-in-the-middle attack could result in the
|
||||
injection of false information. Digital signatures will alleviate
|
||||
this risk, but encrypted transport and tight access lists are a
|
||||
necessary adjunct to them. Since zone files will be distributed to
|
||||
the administrative interfaces of meshed servers, the access control
|
||||
list for distribution of the zone files should include the
|
||||
administrative interface of the server or servers, rather than
|
||||
their shared unicast addresses.
|
||||
|
||||
3.2 Decreased Risks
|
||||
|
||||
The increase in number of physical servers reduces the likelihood
|
||||
that a denial-of-service attack will take out a significant portion
|
||||
of the DNS infrastructure. The increase in servers also reduces
|
||||
the effect of machine crashes, fiber cuts, and localized disasters
|
||||
by reducing the number of users dependent on a specific machine.
|
||||
|
||||
|
||||
4. Full copyright statement
|
||||
|
||||
Copyright (C) The Internet Society 1999. All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain
|
||||
it or assist in its implementation may be prepared, copied,
|
||||
published and distributed, in whole or in part, without restriction
|
||||
of any kind, provided that the above copyright notice and this
|
||||
paragraph are included on all such copies and derivative works.
|
||||
However, this document itself may not be modified in any way, such
|
||||
as by removing the copyright notice or references to the Internet
|
||||
Society or other Internet organizations, except as needed for the
|
||||
purpose of developing Internet standards in which case the
|
||||
procedures for copyrights defined in the Internet Standards process
|
||||
must be followed, or as required to translate it into languages
|
||||
other than English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on
|
||||
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
5. Acknowledgments
|
||||
|
||||
Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
|
||||
Mark Andrews, Robert Elz, Geoff Houston, Bill Norton, Akira Kato,
|
||||
Suzanne Woolf, Scott Tucker, Bernard Aboba, Casey Ajalat and Gunnar
|
||||
Lindberg all provided input and commentary on this work.
|
||||
|
||||
|
||||
6. References
|
||||
|
||||
[SECONDARY] "Selection and Operation of Secondary Name Servers".
|
||||
R. Elz, R. Bush, S Bradner, M. Patton, BCP0016.
|
||||
|
||||
[ROOT] "Root Name Server Operational Requirements". R. Bush,
|
||||
D. Karrenberg, M. Kosters, R. Plzak, BCP0040.
|
||||
|
||||
[ANYCAST] "Host Anycasting Service". C. Patridge, T. Mendez, W. Milliken,
|
||||
RFC1546.
|
||||
|
||||
|
||||
7. Editor's address
|
||||
|
||||
Ted Hardie
|
||||
Nominum, Inc.
|
||||
950 Charter St.
|
||||
Redwood City, CA 94063
|
||||
Ted.Hardie@nominum.com
|
||||
Tel: 1.650.381.6226
|
||||
|
||||
|
||||
|
||||
|
||||
Appendix A.
|
||||
|
||||
|
||||
|
||||
__________________
|
||||
Peer 1-| |
|
||||
Peer 2-| |
|
||||
Peer 3-| Switch |
|
||||
Transit| | _________ _________
|
||||
etc | |--|Router1|---|----|--------------|Router2|---WAN-|
|
||||
| | --------- | | --------- |
|
||||
| | | | |
|
||||
| | | | |
|
||||
------------------ [NTP] [DNS] |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
__________________ |
|
||||
Peer 1-| | |
|
||||
Peer 2-| | |
|
||||
Peer 3-| Switch | |
|
||||
Transit| | _________ _________ |
|
||||
etc | |--|Router3|---|----|--------------|Router4|---WAN-|
|
||||
| | --------- | | --------- |
|
||||
| | | | |
|
||||
| | | | |
|
||||
------------------ [NTP] [DNS] |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
__________________ |
|
||||
Peer 1-| | |
|
||||
Peer 2-| | |
|
||||
Peer 3-| Switch | |
|
||||
Transit| | _________ _________ |
|
||||
etc | |--|Router5|---|----|--------------|Router6|---WAN-|
|
||||
| | --------- | | --------- |
|
||||
| | | | |
|
||||
| | | | |
|
||||
------------------ [NTP] [DNS] |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
__________________ |
|
||||
Peer 1-| | |
|
||||
Peer 2-| | |
|
||||
Peer 3-| Switch | |
|
||||
Transit| | _________ _________ |
|
||||
etc | |--|Router7|---|----|--------------|Router8|---WAN-|
|
||||
| | --------- | | ---------
|
||||
| | | |
|
||||
| | | |
|
||||
------------------ [NTP] [DNS]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,451 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group P. Koch
|
||||
Request for Comments: 3123 Universitaet Bielefeld
|
||||
Category: Experimental June 2001
|
||||
|
||||
|
||||
A DNS RR Type for Lists of Address Prefixes (APL RR)
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This memo defines an Experimental Protocol for the Internet
|
||||
community. It does not specify an Internet standard of any kind.
|
||||
Discussion and suggestions for improvement are requested.
|
||||
Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
The Domain Name System (DNS) is primarily used to translate domain
|
||||
names into IPv4 addresses using A RRs (Resource Records). Several
|
||||
approaches exist to describe networks or address ranges. This
|
||||
document specifies a new DNS RR type "APL" for address prefix lists.
|
||||
|
||||
1. 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 [RFC2119].
|
||||
|
||||
Domain names herein are for explanatory purposes only and should not
|
||||
be expected to lead to useful information in real life [RFC2606].
|
||||
|
||||
2. Background
|
||||
|
||||
The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
|
||||
associate addresses and other Internet infrastructure elements with
|
||||
hierarchically built domain names. Various types of resource records
|
||||
have been defined, especially those for IPv4 and IPv6 [RFC2874]
|
||||
addresses. In [RFC1101] a method is described to publish information
|
||||
about the address space allocated to an organisation. In older BIND
|
||||
versions, a weak form of controlling access to zone data was
|
||||
implemented using TXT RRs describing address ranges.
|
||||
|
||||
This document specifies a new RR type for address prefix lists.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Koch Experimental [Page 1]
|
||||
|
||||
RFC 3123 DNS APL RR June 2001
|
||||
|
||||
|
||||
3. APL RR Type
|
||||
|
||||
An APL record has the DNS type of "APL" and a numeric value of 42
|
||||
[IANA]. The APL RR is defined in the IN class only. APL RRs cause
|
||||
no additional section processing.
|
||||
|
||||
4. APL RDATA format
|
||||
|
||||
The RDATA section consists of zero or more items (<apitem>) of the
|
||||
form
|
||||
|
||||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
| ADDRESSFAMILY |
|
||||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
| PREFIX | N | AFDLENGTH |
|
||||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
/ AFDPART /
|
||||
| |
|
||||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
|
||||
ADDRESSFAMILY 16 bit unsigned value as assigned by IANA
|
||||
(see IANA Considerations)
|
||||
PREFIX 8 bit unsigned binary coded prefix length.
|
||||
Upper and lower bounds and interpretation of
|
||||
this value are address family specific.
|
||||
N negation flag, indicates the presence of the
|
||||
"!" character in the textual format. It has
|
||||
the value "1" if the "!" was given, "0" else.
|
||||
AFDLENGTH length in octets of the following address
|
||||
family dependent part (7 bit unsigned).
|
||||
AFDPART address family dependent part. See below.
|
||||
|
||||
This document defines the AFDPARTs for address families 1 (IPv4) and
|
||||
2 (IPv6). Future revisions may deal with additional address
|
||||
families.
|
||||
|
||||
4.1. AFDPART for IPv4
|
||||
|
||||
The encoding of an IPv4 address (address family 1) follows the
|
||||
encoding specified for the A RR by [RFC1035], section 3.4.1.
|
||||
|
||||
PREFIX specifies the number of bits of the IPv4 address starting at
|
||||
the most significant bit. Legal values range from 0 to 32.
|
||||
|
||||
Trailing zero octets do not bear any information (e.g., there is no
|
||||
semantic difference between 10.0.0.0/16 and 10/16) in an address
|
||||
prefix, so the shortest possible AFDLENGTH can be used to encode it.
|
||||
However, for DNSSEC [RFC2535] a single wire encoding must be used by
|
||||
|
||||
|
||||
|
||||
Koch Experimental [Page 2]
|
||||
|
||||
RFC 3123 DNS APL RR June 2001
|
||||
|
||||
|
||||
all. Therefore the sender MUST NOT include trailing zero octets in
|
||||
the AFDPART regardless of the value of PREFIX. This includes cases
|
||||
in which AFDLENGTH times 8 results in a value less than PREFIX. The
|
||||
AFDPART is padded with zero bits to match a full octet boundary.
|
||||
|
||||
An IPv4 AFDPART has a variable length of 0 to 4 octets.
|
||||
|
||||
4.2. AFDPART for IPv6
|
||||
|
||||
The 128 bit IPv6 address (address family 2) is encoded in network
|
||||
byte order (high-order byte first).
|
||||
|
||||
PREFIX specifies the number of bits of the IPv6 address starting at
|
||||
the most significant bit. Legal values range from 0 to 128.
|
||||
|
||||
With the same reasoning as in 4.1 above, the sender MUST NOT include
|
||||
trailing zero octets in the AFDPART regardless of the value of
|
||||
PREFIX. This includes cases in which AFDLENGTH times 8 results in a
|
||||
value less than PREFIX. The AFDPART is padded with zero bits to
|
||||
match a full octet boundary.
|
||||
|
||||
An IPv6 AFDPART has a variable length of 0 to 16 octets.
|
||||
|
||||
5. Zone File Syntax
|
||||
|
||||
The textual representation of an APL RR in a DNS zone file is as
|
||||
follows:
|
||||
|
||||
<owner> IN <TTL> APL {[!]afi:address/prefix}*
|
||||
|
||||
The data consists of zero or more strings of the address family
|
||||
indicator <afi>, immediately followed by a colon ":", an address,
|
||||
immediately followed by the "/" character, immediately followed by a
|
||||
decimal numeric value for the prefix length. Any such string may be
|
||||
preceded by a "!" character. The strings are separated by
|
||||
whitespace. The <afi> is the decimal numeric value of that
|
||||
particular address family.
|
||||
|
||||
5.1. Textual Representation of IPv4 Addresses
|
||||
|
||||
An IPv4 address in the <address> part of an <apitem> is in dotted
|
||||
quad notation, just as in an A RR. The <prefix> has values from the
|
||||
interval 0..32 (decimal).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Koch Experimental [Page 3]
|
||||
|
||||
RFC 3123 DNS APL RR June 2001
|
||||
|
||||
|
||||
5.2. Textual Representation of IPv6 Addresses
|
||||
|
||||
The representation of an IPv6 address in the <address> part of an
|
||||
<apitem> follows [RFC2373], section 2.2. Legal values for <prefix>
|
||||
are from the interval 0..128 (decimal).
|
||||
|
||||
6. APL RR usage
|
||||
|
||||
An APL RR with empty RDATA is valid and implements an empty list.
|
||||
Multiple occurrences of the same <apitem> in a single APL RR are
|
||||
allowed and MUST NOT be merged by a DNS server or resolver.
|
||||
<apitems> MUST be kept in order and MUST NOT be rearranged or
|
||||
aggregated.
|
||||
|
||||
A single APL RR may contain <apitems> belonging to different address
|
||||
families. The maximum number of <apitems> is upper bounded by the
|
||||
available RDATA space.
|
||||
|
||||
RRSets consisting of more than one APL RR are legal but the
|
||||
interpretation is left to the particular application.
|
||||
|
||||
7. Applicability Statement
|
||||
|
||||
The APL RR defines a framework without specifying any particular
|
||||
meaning for the list of prefixes. It is expected that APL RRs will
|
||||
be used in different application scenarios which have to be
|
||||
documented separately. Those scenarios may be distinguished by
|
||||
characteristic prefixes placed in front of the DNS owner name.
|
||||
|
||||
An APL application specification MUST include information on
|
||||
|
||||
o the characteristic prefix, if any
|
||||
|
||||
o how to interpret APL RRSets consisting of more than one RR
|
||||
|
||||
o how to interpret an empty APL RR
|
||||
|
||||
o which address families are expected to appear in the APL RRs for
|
||||
that application
|
||||
|
||||
o how to deal with APL RR list elements which belong to other
|
||||
address families, including those not yet defined
|
||||
|
||||
o the exact semantics of list elements negated by the "!" character
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Koch Experimental [Page 4]
|
||||
|
||||
RFC 3123 DNS APL RR June 2001
|
||||
|
||||
|
||||
Possible applications include the publication of address ranges
|
||||
similar to [RFC1101], description of zones built following [RFC2317]
|
||||
and in-band access control to limit general access or zone transfer
|
||||
(AXFR) availability for zone data held in DNS servers.
|
||||
|
||||
The specification of particular application scenarios is out of the
|
||||
scope of this document.
|
||||
|
||||
8. Examples
|
||||
|
||||
The following examples only illustrate some of the possible usages
|
||||
outlined in the previous section. None of those applications are
|
||||
hereby specified nor is it implied that any particular APL RR based
|
||||
application does exist now or will exist in the future.
|
||||
|
||||
; RFC 1101-like announcement of address ranges for foo.example
|
||||
foo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
|
||||
|
||||
; CIDR blocks covered by classless delegation
|
||||
42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
|
||||
1:192.168.42.128/25 )
|
||||
|
||||
; Zone transfer restriction
|
||||
_axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22
|
||||
|
||||
; List of address ranges for multicast
|
||||
multicast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
|
||||
|
||||
Note that since trailing zeroes are ignored in the first APL RR the
|
||||
AFDLENGTH of both <apitems> is three.
|
||||
|
||||
9. Security Considerations
|
||||
|
||||
Any information obtained from the DNS should be regarded as unsafe
|
||||
unless techniques specified in [RFC2535] or [RFC2845] were used. The
|
||||
definition of a new RR type does not introduce security problems into
|
||||
the DNS, but usage of information made available by APL RRs may
|
||||
compromise security. This includes disclosure of network topology
|
||||
information and in particular the use of APL RRs to construct access
|
||||
control lists.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Koch Experimental [Page 5]
|
||||
|
||||
RFC 3123 DNS APL RR June 2001
|
||||
|
||||
|
||||
10. IANA Considerations
|
||||
|
||||
This section is to be interpreted as following [RFC2434].
|
||||
|
||||
This document does not define any new namespaces. It uses the 16 bit
|
||||
identifiers for address families maintained by IANA in
|
||||
http://www.iana.org/numbers.html.
|
||||
|
||||
The IANA assigned numeric RR type value 42 for APL [IANA].
|
||||
|
||||
11. Acknowledgements
|
||||
|
||||
The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
|
||||
Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
|
||||
and constructive comments.
|
||||
|
||||
12. References
|
||||
|
||||
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
|
||||
STD 13, RFC 1034, November 1987.
|
||||
|
||||
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
|
||||
Specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other
|
||||
Types", RFC 1101, April 1989.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
|
||||
Specification", RFC 2181, July 1997.
|
||||
|
||||
[RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
|
||||
ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
|
||||
|
||||
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
|
||||
Architecture", RFC 2373, July 1998.
|
||||
|
||||
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
|
||||
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
|
||||
October 1998.
|
||||
|
||||
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
|
||||
2535, March 1999.
|
||||
|
||||
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
|
||||
BCP 32, RFC 2606, June 1999.
|
||||
|
||||
|
||||
|
||||
Koch Experimental [Page 6]
|
||||
|
||||
RFC 3123 DNS APL RR June 2001
|
||||
|
||||
|
||||
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
|
||||
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
|
||||
2845, May 2000.
|
||||
|
||||
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
|
||||
IPv6 Address Aggregation and Renumbering", RFC 2874, July
|
||||
2000.
|
||||
|
||||
[IANA] http://www.iana.org/assignments/dns-parameters
|
||||
|
||||
13. Author's Address
|
||||
|
||||
Peter Koch
|
||||
Universitaet Bielefeld
|
||||
Technische Fakultaet
|
||||
D-33594 Bielefeld
|
||||
Germany
|
||||
|
||||
Phone: +49 521 106 2902
|
||||
EMail: pk@TechFak.Uni-Bielefeld.DE
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Koch Experimental [Page 7]
|
||||
|
||||
RFC 3123 DNS APL RR June 2001
|
||||
|
||||
|
||||
14. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Koch Experimental [Page 8]
|
||||
|
||||
@@ -1,227 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group R. Bush
|
||||
Request for Comments: 3152 RGnet
|
||||
BCP: 49 August 2001
|
||||
Updates: 2874, 2772, 2766, 2553, 1886
|
||||
Category: Best Current Practice
|
||||
|
||||
|
||||
Delegation of IP6.ARPA
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet Best Current Practices for the
|
||||
Internet Community, and requests discussion and suggestions for
|
||||
improvements. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
This document discusses the need for delegation of the IP6.ARPA DNS
|
||||
zone, and specifies a plan for the technical operation thereof.
|
||||
|
||||
1. Why IP6.ARPA?
|
||||
|
||||
In the IPv6 address space, there is a need for 'reverse mapping' of
|
||||
addresses to DNS names analogous to that provided by the IN-ADDR.ARPA
|
||||
zone for IPv4.
|
||||
|
||||
The IAB recommended that the ARPA top level domain (the name is now
|
||||
considered an acronym for "Address and Routing Parameters Area") be
|
||||
used for technical infrastructure sub-domains when possible. It is
|
||||
already in use for IPv4 reverse mapping and has been established as
|
||||
the location for E.164 numbering on the Internet [RFC2916 RFC3026].
|
||||
|
||||
IETF consensus was reached that the IP6.ARPA domain be used for
|
||||
address to DNS name mapping for the IPv6 address space [RFC2874].
|
||||
|
||||
2. Obsoleted Usage
|
||||
|
||||
This document deprecates references to IP6.INT in [RFC1886] section
|
||||
2.5, [RFC2553] section 6.2.3, [RFC2766] section 4.1, [RFC2772]
|
||||
section 7.1.c, and [RFC2874] section 2.5.
|
||||
|
||||
In this context, 'deprecate' means that the old usage is not
|
||||
appropriate for new implementations, and IP6.INT will likely be
|
||||
phased out in an orderly fashion.
|
||||
|
||||
|
||||
|
||||
Bush Best Current Practice [Page 1]
|
||||
|
||||
RFC 3152 Delegation of IP6.ARPA August 2001
|
||||
|
||||
|
||||
3. IANA Considerations
|
||||
|
||||
This memo requests that the IANA delegate the IP6.ARPA domain
|
||||
following instructions to be provided by the IAB. Names within this
|
||||
zone are to be further delegated to the regional IP registries in
|
||||
accordance with the delegation of IPv6 address space to those
|
||||
registries. The names allocated should be hierarchic in accordance
|
||||
with the address space assignment.
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
While DNS spoofing of address to name mapping has been exploited in
|
||||
IPv4, delegation of the IP6.ARPA zone creates no new threats to the
|
||||
security of the internet.
|
||||
|
||||
5. References
|
||||
|
||||
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP
|
||||
version 6", RFC 1886, December 1995.
|
||||
|
||||
[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
|
||||
"Basic Socket Interface Extensions for IPv6", RFC 2553,
|
||||
March 1999.
|
||||
|
||||
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
|
||||
Translation - Protocol Translation (NAT-PT)", RFC 2766,
|
||||
February 2000.
|
||||
|
||||
[RFC2772] Rockell, R. and R. Fink, "6Bone Backbone Routing
|
||||
Guidelines", RFC 2772, February 2000.
|
||||
|
||||
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
|
||||
IPv6 Address Aggregation and Renumbering", RFC 2874, July
|
||||
2001.
|
||||
|
||||
[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916,
|
||||
September 2000.
|
||||
|
||||
[RFC3026] Blane, R., "Liaison to IETF/ISOC on ENUM", RFC 3026,
|
||||
January 2001.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Bush Best Current Practice [Page 2]
|
||||
|
||||
RFC 3152 Delegation of IP6.ARPA August 2001
|
||||
|
||||
|
||||
6. Author's Address
|
||||
|
||||
Randy Bush
|
||||
5147 Crystal Springs
|
||||
Bainbridge Island, WA US-98110
|
||||
|
||||
Phone: +1 206 780 0431
|
||||
EMail: randy@psg.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Bush Best Current Practice [Page 3]
|
||||
|
||||
RFC 3152 Delegation of IP6.ARPA August 2001
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Bush Best Current Practice [Page 4]
|
||||
|
||||
@@ -1,339 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group D. Conrad
|
||||
Request for Comments: 3225 Nominum, Inc.
|
||||
Category: Standards Track December 2001
|
||||
|
||||
|
||||
Indicating Resolver Support of DNSSEC
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
In order to deploy DNSSEC (Domain Name System Security Extensions)
|
||||
operationally, DNSSEC aware servers should only perform automatic
|
||||
inclusion of DNSSEC RRs when there is an explicit indication that the
|
||||
resolver can understand those RRs. This document proposes the use of
|
||||
a bit in the EDNS0 header to provide that explicit indication and
|
||||
describes the necessary protocol changes to implement that
|
||||
notification.
|
||||
|
||||
1. Introduction
|
||||
|
||||
DNSSEC [RFC2535] has been specified to provide data integrity and
|
||||
authentication to security aware resolvers and applications through
|
||||
the use of cryptographic digital signatures. However, as DNSSEC is
|
||||
deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
|
||||
servers. In such situations, the DNSSEC-aware server (responding to
|
||||
a request for data in a signed zone) will respond with SIG, KEY,
|
||||
and/or NXT records. For reasons described in the subsequent section,
|
||||
such responses can have significant negative operational impacts for
|
||||
the DNS infrastructure.
|
||||
|
||||
This document discusses a method to avoid these negative impacts,
|
||||
namely DNSSEC-aware servers should only respond with SIG, KEY, and/or
|
||||
NXT RRs when there is an explicit indication from the resolver that
|
||||
it can understand those RRs.
|
||||
|
||||
For the purposes of this document, "DNSSEC security RRs" are
|
||||
considered RRs of type SIG, KEY, or NXT.
|
||||
|
||||
|
||||
|
||||
Conrad Standards Track [Page 1]
|
||||
|
||||
RFC 3225 Indicating Resolver Support of DNSSEC December 2001
|
||||
|
||||
|
||||
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 [RFC2119].
|
||||
|
||||
2. Rationale
|
||||
|
||||
Initially, as DNSSEC is deployed, the vast majority of queries will
|
||||
be from resolvers that are not DNSSEC aware and thus do not
|
||||
understand or support the DNSSEC security RRs. When a query from
|
||||
such a resolver is received for a DNSSEC signed zone, the DNSSEC
|
||||
specification indicates the nameserver must respond with the
|
||||
appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to
|
||||
512 bytes [RFC1035], responses including DNSSEC security RRs have a
|
||||
high probability of resulting in a truncated response being returned
|
||||
and the resolver retrying the query using TCP.
|
||||
|
||||
TCP DNS queries result in significant overhead due to connection
|
||||
setup and teardown. Operationally, the impact of these TCP queries
|
||||
will likely be quite detrimental in terms of increased network
|
||||
traffic (typically five packets for a single query/response instead
|
||||
of two), increased latency resulting from the additional round trip
|
||||
times, increased incidences of queries failing due to timeouts, and
|
||||
significantly increased load on nameservers.
|
||||
|
||||
In addition, in preliminary and experimental deployment of DNSSEC,
|
||||
there have been reports of non-DNSSEC aware resolvers being unable to
|
||||
handle responses which contain DNSSEC security RRs, resulting in the
|
||||
resolver failing (in the worst case) or entire responses being
|
||||
ignored (in the better case).
|
||||
|
||||
Given these operational implications, explicitly notifying the
|
||||
nameserver that the client is prepared to receive (if not understand)
|
||||
DNSSEC security RRs would be prudent.
|
||||
|
||||
Client-side support of DNSSEC is assumed to be binary -- either the
|
||||
client is willing to receive all DNSSEC security RRs or it is not
|
||||
willing to accept any. As such, a single bit is sufficient to
|
||||
indicate client-side DNSSEC support. As effective use of DNSSEC
|
||||
implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
|
||||
enhanced DNS header) are scarce, and there may be situations in which
|
||||
non-compliant caching or forwarding servers inappropriately copy data
|
||||
from classic headers as queries are passed on to authoritative
|
||||
servers, the use of a bit from the EDNS0 header is proposed.
|
||||
|
||||
An alternative approach would be to use the existence of an EDNS0
|
||||
header as an implicit indication of client-side support of DNSSEC.
|
||||
This approach was not chosen as there may be applications in which
|
||||
EDNS0 is supported but in which the use of DNSSEC is inappropriate.
|
||||
|
||||
|
||||
|
||||
Conrad Standards Track [Page 2]
|
||||
|
||||
RFC 3225 Indicating Resolver Support of DNSSEC December 2001
|
||||
|
||||
|
||||
3. Protocol Changes
|
||||
|
||||
The mechanism chosen for the explicit notification of the ability of
|
||||
the client to accept (if not understand) DNSSEC security RRs is using
|
||||
the most significant bit of the Z field on the EDNS0 OPT header in
|
||||
the query. This bit is referred to as the "DNSSEC OK" (DO) bit. In
|
||||
the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
|
||||
the third and fourth bytes of the "extended RCODE and flags" portion
|
||||
of the EDNS0 OPT meta-RR, structured as follows:
|
||||
|
||||
+0 (MSB) +1 (LSB)
|
||||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||
0: | EXTENDED-RCODE | VERSION |
|
||||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||
2: |DO| Z |
|
||||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||
|
||||
Setting the DO bit to one in a query indicates to the server that the
|
||||
resolver is able to accept DNSSEC security RRs. The DO bit cleared
|
||||
(set to zero) indicates the resolver is unprepared to handle DNSSEC
|
||||
security RRs and those RRs MUST NOT be returned in the response
|
||||
(unless DNSSEC security RRs are explicitly queried for). The DO bit
|
||||
of the query MUST be copied in the response.
|
||||
|
||||
More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
|
||||
or NXT RRs to authenticate a response as specified in [RFC2535]
|
||||
unless the DO bit was set on the request. Security records that
|
||||
match an explicit SIG, KEY, NXT, or ANY query, or are part of the
|
||||
zone data for an AXFR or IXFR query, are included whether or not the
|
||||
DO bit was set.
|
||||
|
||||
A recursive DNSSEC-aware server MUST set the DO bit on recursive
|
||||
requests, regardless of the status of the DO bit on the initiating
|
||||
resolver request. If the initiating resolver request does not have
|
||||
the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
|
||||
security RRs before returning the data to the client, however cached
|
||||
data MUST NOT be modified.
|
||||
|
||||
In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
|
||||
to a query that has the DO bit set, the resolver SHOULD NOT expect
|
||||
DNSSEC security RRs and SHOULD retry the query without EDNS0 in
|
||||
accordance with section 5.3 of [RFC2671].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Conrad Standards Track [Page 3]
|
||||
|
||||
RFC 3225 Indicating Resolver Support of DNSSEC December 2001
|
||||
|
||||
|
||||
Security Considerations
|
||||
|
||||
The absence of DNSSEC data in response to a query with the DO bit set
|
||||
MUST NOT be taken to mean no security information is available for
|
||||
that zone as the response may be forged or a non-forged response of
|
||||
an altered (DO bit cleared) query.
|
||||
|
||||
IANA Considerations
|
||||
|
||||
EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record,
|
||||
these bits are encoded into the TTL field of the OPT record (RFC2671
|
||||
section 4.6).
|
||||
|
||||
This document reserves one of these bits as the OK bit. It is
|
||||
requested that the left most bit be allocated. Thus the USE of the
|
||||
OPT record TTL field would look like
|
||||
|
||||
+0 (MSB) +1 (LSB)
|
||||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||
0: | EXTENDED-RCODE | VERSION |
|
||||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||
2: |DO| Z |
|
||||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||
|
||||
Acknowledgements
|
||||
|
||||
This document is based on a rough draft by Bob Halley with input from
|
||||
Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
|
||||
Rob Austein, Steve Bellovin, and Erik Nordmark.
|
||||
|
||||
References
|
||||
|
||||
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
|
||||
STD 13, RFC 1034, November 1987.
|
||||
|
||||
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
|
||||
Specifications", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
|
||||
2535, March 1999.
|
||||
|
||||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
|
||||
2671, August 1999.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Conrad Standards Track [Page 4]
|
||||
|
||||
RFC 3225 Indicating Resolver Support of DNSSEC December 2001
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
David Conrad
|
||||
Nominum Inc.
|
||||
950 Charter Street
|
||||
Redwood City, CA 94063
|
||||
USA
|
||||
|
||||
Phone: +1 650 381 6003
|
||||
EMail: david.conrad@nominum.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Conrad Standards Track [Page 5]
|
||||
|
||||
RFC 3225 Indicating Resolver Support of DNSSEC December 2001
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Conrad Standards Track [Page 6]
|
||||
|
||||
@@ -1,339 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group O. Gudmundsson
|
||||
Request for Comments: 3226 December 2001
|
||||
Updates: 2874, 2535
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
DNSSEC and IPv6 A6 aware server/resolver message size requirements
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
This document mandates support for EDNS0 (Extension Mechanisms for
|
||||
DNS) in DNS entities claiming to support either DNS Security
|
||||
Extensions or A6 records. This requirement is necessary because
|
||||
these new features increase the size of DNS messages. If EDNS0 is
|
||||
not supported fall back to TCP will happen, having a detrimental
|
||||
impact on query latency and DNS server load. This document updates
|
||||
RFC 2535 and RFC 2874, by adding new requirements.
|
||||
|
||||
1. Introduction
|
||||
|
||||
Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions
|
||||
[RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful.
|
||||
|
||||
STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP
|
||||
have a data payload of 512 octets or less. Most DNS software today
|
||||
will not accept larger UDP datagrams. Any answer that requires more
|
||||
than 512 octets, results in a partial and sometimes useless reply
|
||||
with the Truncation Bit set; in most cases the requester will then
|
||||
retry using TCP. Furthermore, server delivery of truncated responses
|
||||
varies widely and resolver handling of these responses also varies,
|
||||
leading to additional inefficiencies in handling truncation.
|
||||
|
||||
Compared to UDP, TCP is an expensive protocol to use for a simple
|
||||
transaction like DNS: a TCP connection requires 5 packets for setup
|
||||
and tear down, excluding data packets, thus requiring at least 3
|
||||
round trips on top of the one for the original UDP query. The DNS
|
||||
|
||||
|
||||
|
||||
Gudmundsson Standards Track [Page 1]
|
||||
|
||||
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
|
||||
|
||||
|
||||
server also needs to keep a state of the connection during this
|
||||
transaction. Many DNS servers answer thousands of queries per
|
||||
second, requiring them to use TCP will cause significant overhead and
|
||||
delays.
|
||||
|
||||
1.1. Requirements
|
||||
|
||||
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
|
||||
in this document are to be interpreted as described in RFC 2119.
|
||||
|
||||
2. Motivating factors
|
||||
|
||||
2.1. DNSSEC motivations
|
||||
|
||||
DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each
|
||||
RR set. These signatures range in size from about 80 octets to 800
|
||||
octets, most are going to be in the range of 80 to 200 octets. The
|
||||
addition of signatures on each or most RR sets in an answer
|
||||
significantly increases the size of DNS answers from secure zones.
|
||||
|
||||
For performance reasons and to reduce load on DNS servers, it is
|
||||
important that security aware servers and resolvers get all the data
|
||||
in Answer and Authority section in one query without truncation.
|
||||
Sending Additional Data in the same query is helpful when the server
|
||||
is authoritative for the data, and this reduces round trips.
|
||||
|
||||
DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that
|
||||
it is interested in receiving DNSSEC records. The OK bit does not
|
||||
eliminate the need for large answers for DNSSEC capable clients.
|
||||
|
||||
2.1.1. Message authentication or TSIG motivation
|
||||
|
||||
TSIG [RFC2845] allows for the light weight authentication of DNS
|
||||
messages, but increases the size of the messages by at least 70
|
||||
octets. DNSSEC specifies for computationally expensive message
|
||||
authentication SIG(0) using a standard public key signature. As only
|
||||
one TSIG or SIG(0) can be attached to each DNS answer the size
|
||||
increase of message authentication is not significant, but may still
|
||||
lead to a truncation.
|
||||
|
||||
2.2. IPv6 Motivations
|
||||
|
||||
IPv6 addresses [RFC2874] are 128 bits and can be represented in the
|
||||
DNS by multiple A6 records, each consisting of a domain name and a
|
||||
bit field. The domain name refers to an address prefix that may
|
||||
require additional A6 RRs to be included in the answer. Answers
|
||||
where the queried name has multiple A6 addresses may overflow a 512-
|
||||
octet UDP packet size.
|
||||
|
||||
|
||||
|
||||
Gudmundsson Standards Track [Page 2]
|
||||
|
||||
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
|
||||
|
||||
|
||||
2.3. Root server and TLD server motivations
|
||||
|
||||
The current number of root servers is limited to 13 as that is the
|
||||
maximum number of name servers and their address records that fit in
|
||||
one 512-octet answer for a SOA record. If root servers start
|
||||
advertising A6 or KEY records then the answer for the root NS records
|
||||
will not fit in a single 512-octet DNS message, resulting in a large
|
||||
number of TCP query connections to the root servers. Even if all
|
||||
client resolver query their local name server for information, there
|
||||
are millions of these servers. Each name server must periodically
|
||||
update its information about the high level servers.
|
||||
|
||||
For redundancy, latency and load balancing reasons, large numbers of
|
||||
DNS servers are required for some zones. Since the root zone is used
|
||||
by the entire net, it is important to have as many servers as
|
||||
possible. Large TLDs (and many high-visibility SLDs) often have
|
||||
enough servers that either A6 or KEY records would cause the NS
|
||||
response to overflow the 512 byte limit. Note that these zones with
|
||||
large numbers of servers are often exactly those zones that are
|
||||
critical to network operation and that already sustain fairly high
|
||||
loads.
|
||||
|
||||
2.4. UDP vs TCP for DNS messages
|
||||
|
||||
Given all these factors, it is essential that any implementation that
|
||||
supports DNSSEC and or A6 be able to use larger DNS messages than 512
|
||||
octets.
|
||||
|
||||
The original 512 restriction was put in place to reduce the
|
||||
probability of fragmentation of DNS responses. A fragmented UDP
|
||||
message that suffers a loss of one of the fragments renders the
|
||||
answer useless and the query must be retried. A TCP connection
|
||||
requires a larger number of round trips for establishment, data
|
||||
transfer and tear down, but only the lost data segments are
|
||||
retransmitted.
|
||||
|
||||
In the early days a number of IP implementations did not handle
|
||||
fragmentation well, but all modern operating systems have overcome
|
||||
that issue thus sending fragmented messages is fine from that
|
||||
standpoint. The open issue is the effect of losses on fragmented
|
||||
messages. If connection has high loss ratio only TCP will allow
|
||||
reliable transfer of DNS data, most links have low loss ratios thus
|
||||
sending fragmented UDP packet in one round trip is better than
|
||||
establishing a TCP connection to transfer a few thousand octets.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gudmundsson Standards Track [Page 3]
|
||||
|
||||
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
|
||||
|
||||
|
||||
2.5. EDNS0 and large UDP messages
|
||||
|
||||
EDNS0 [RFC2671] allows clients to declare the maximum size of UDP
|
||||
message they are willing to handle. Thus, if the expected answer is
|
||||
between 512 octets and the maximum size that the client can accept,
|
||||
the additional overhead of a TCP connection can be avoided.
|
||||
|
||||
3. Protocol changes:
|
||||
|
||||
This document updates RFC 2535 and RFC 2874, by adding new
|
||||
requirements.
|
||||
|
||||
All RFC 2535 compliant servers and resolvers MUST support EDNS0 and
|
||||
advertise message size of at least 1220 octets, but SHOULD advertise
|
||||
message size of 4000. This value might be too low to get full
|
||||
answers for high level servers and successor of this document may
|
||||
require a larger value.
|
||||
|
||||
All RFC 2874 compliant servers and resolver MUST support EDNS0 and
|
||||
advertise message size of at least 1024 octets, but SHOULD advertise
|
||||
message size of 2048. The IPv6 datagrams should be 1024 octets,
|
||||
unless the MTU of the path is known. (Note that this is smaller than
|
||||
the minimum IPv6 MTU to allow for some extension headers and/or
|
||||
encapsulation without exceeding the minimum MTU.)
|
||||
|
||||
All RFC 2535 and RFC 2874 compliant entities MUST be able to handle
|
||||
fragmented IPv4 and IPv6 UDP packets.
|
||||
|
||||
All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger
|
||||
required value in EDNS0 advertisements.
|
||||
|
||||
4. Acknowledgments
|
||||
|
||||
Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas
|
||||
Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis
|
||||
Michael Patton and Kazu Yamamoto were instrumental in motivating and
|
||||
shaping this document.
|
||||
|
||||
5. Security Considerations:
|
||||
|
||||
There are no additional security considerations other than those in
|
||||
RFC 2671.
|
||||
|
||||
6. IANA Considerations:
|
||||
|
||||
None
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gudmundsson Standards Track [Page 4]
|
||||
|
||||
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
|
||||
|
||||
|
||||
7. References
|
||||
|
||||
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
|
||||
STD 13, RFC 1034, November 1987.
|
||||
|
||||
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
|
||||
Specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[RFC2535] Eastlake, D. "Domain Name System Security Extensions", RFC
|
||||
2535, March 1999.
|
||||
|
||||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
|
||||
2671, August 1999.
|
||||
|
||||
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
|
||||
Wellington, "Secret Key Transaction Authentication for DNS
|
||||
(TSIG)", RFC 2845, May 2000.
|
||||
|
||||
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
|
||||
IPv6 Address Aggregation and Renumbering", RFC 2874, July
|
||||
2000.
|
||||
|
||||
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
|
||||
3225, December 2001.
|
||||
|
||||
8. Author Address
|
||||
|
||||
Olafur Gudmundsson
|
||||
3826 Legation Street, NW
|
||||
Washington, DC 20015
|
||||
USA
|
||||
|
||||
EMail: ogud@ogud.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gudmundsson Standards Track [Page 5]
|
||||
|
||||
RFC 3226 DNSSEC and IPv6 A6 requirements December 2001
|
||||
|
||||
|
||||
9. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2001). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Gudmundsson Standards Track [Page 6]
|
||||
|
||||
@@ -1,619 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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
|
||||
|
||||
In order to minimize the risk of man-in-the-middle attacks, zone
|
||||
files should be delivered to the administrative interface of the
|
||||
servers participating in the mesh. Secure file transfer methods and
|
||||
strong authentication should be used for all transfers. If the hosts
|
||||
in the mesh make their zones available for zone transfer, the
|
||||
administrative interfaces should be used for those transfers as well,
|
||||
in order to avoid the problems with potential routing changes for TCP
|
||||
traffic noted in section 2.5 below.
|
||||
|
||||
2.3 Synchronization
|
||||
|
||||
Authoritative name servers may be loosely or tightly synchronized,
|
||||
depending on the practices set by the operating organization. As
|
||||
noted below in section 4.1.2, lack of synchronization among servers
|
||||
using the same shared unicast address could create problems for some
|
||||
users of this service. In order to minimize that risk, switch-overs
|
||||
from one data set to another data set should be coordinated as much
|
||||
as possible. The use of synchronized clocks on the participating
|
||||
hosts and set times for switch-overs provides a basic level of
|
||||
coordination. A more complete coordination process would involve:
|
||||
|
||||
a) receipt of zones at a distribution host
|
||||
b) confirmation of the integrity of zones received
|
||||
c) distribution of the zones to all of the servers in the mesh
|
||||
d) confirmation of the integrity of the zones at each server
|
||||
|
||||
|
||||
|
||||
|
||||
Hardie Informational [Page 2]
|
||||
|
||||
RFC 3258 Distributing Authoritative Name Servers April 2002
|
||||
|
||||
|
||||
e) coordination of the switchover times for the servers in the
|
||||
mesh
|
||||
f) institution of a failure process to ensure that servers that
|
||||
did not receive correct data or could not switchover to the new
|
||||
data ceased to respond to incoming queries until the problem
|
||||
could be resolved.
|
||||
|
||||
Depending on the size of the mesh, the distribution host may also be
|
||||
a participant; for authoritative servers, it may also be the host on
|
||||
which zones are generated.
|
||||
|
||||
This document presumes that the usual DNS failover methods are the
|
||||
only ones used to ensure reachability of the data for clients. It
|
||||
does not advise that the routes be withdrawn in the case of failure;
|
||||
it advises instead that the DNS process shutdown so that servers on
|
||||
other addresses are queried. This recommendation reflects a choice
|
||||
between performance and operational complexity. While it would be
|
||||
possible to have some process withdraw the route for a specific
|
||||
server instance when it is not available, there is considerable
|
||||
operational complexity involved in ensuring that this occurs
|
||||
reliably. Given the existing DNS failover methods, the marginal
|
||||
improvement in performance will not be sufficient to justify the
|
||||
additional complexity for most uses.
|
||||
|
||||
2.4 Server Placement
|
||||
|
||||
Though the geographic diversity of server placement helps reduce the
|
||||
effects of service disruptions due to local problems, it is diversity
|
||||
of placement in the network topology which is the driving force
|
||||
behind these distribution practices. Server placement should
|
||||
emphasize that diversity. Ideally, servers should be placed
|
||||
topologically near the points at which the operator exchanges routes
|
||||
and traffic with other networks.
|
||||
|
||||
2.5 Routing
|
||||
|
||||
The organization administering the mesh of servers sharing a unicast
|
||||
address must have an autonomous system number and speak BGP to its
|
||||
peers. To those peers, the organization announces a route to the
|
||||
network containing the shared-unicast address of the name server.
|
||||
The organization's border routers must then deliver the traffic
|
||||
destined for the name server to the nearest instantiation. Routing
|
||||
to the administrative interfaces for the servers can use the normal
|
||||
routing methods for the administering organization.
|
||||
|
||||
One potential problem with using shared unicast addresses is that
|
||||
routers forwarding traffic to them may have more than one available
|
||||
route, and those routes may, in fact, reach different instances of
|
||||
|
||||
|
||||
|
||||
Hardie Informational [Page 3]
|
||||
|
||||
RFC 3258 Distributing Authoritative Name Servers April 2002
|
||||
|
||||
|
||||
the shared unicast address. Applications like the DNS, whose
|
||||
communication typically consists of independent request-response
|
||||
messages each fitting in a single UDP packet present no problem.
|
||||
Other applications, in which multiple packets must reach the same
|
||||
endpoint (e.g., TCP) may fail or present unworkable performance
|
||||
characteristics in some circumstances. Split-destination failures
|
||||
may occur when a router does per-packet (or round-robin) load
|
||||
sharing, a topology change occurs that changes the relative metrics
|
||||
of two paths to the same anycast destination, etc.
|
||||
|
||||
Four things mitigate the severity of this problem. The first is that
|
||||
UDP is a fairly high proportion of the query traffic to name servers.
|
||||
The second is that the aim of this proposal is to diversify
|
||||
topological placement; for most users, this means that the
|
||||
coordination of placement will ensure that new instances of a name
|
||||
server will be at a significantly different cost metric from existing
|
||||
instances. Some set of users may end up in the middle, but that
|
||||
should be relatively rare. The third is that per packet load sharing
|
||||
is only one of the possible load sharing mechanisms, and other
|
||||
mechanisms are increasing in popularity.
|
||||
|
||||
Lastly, in the case where the traffic is TCP, per packet load sharing
|
||||
is used, and equal cost routes to different instances of a name
|
||||
server are available, any DNS implementation which measures the
|
||||
performance of servers to select a preferred server will quickly
|
||||
prefer a server for which this problem does not occur. For the DNS
|
||||
failover mechanisms to reliably avoid this problem, however, those
|
||||
using shared unicast distribution mechanisms must take care that all
|
||||
of the servers for a specific zone are not participants in the same
|
||||
shared-unicast mesh. To guard even against the case where multiple
|
||||
meshes have a set of users affected by per packet load sharing along
|
||||
equal cost routes, organizations implementing these practices should
|
||||
always provide at least one authoritative server which is not a
|
||||
participant in any shared unicast mesh. Those deploying shared-
|
||||
unicast meshes should note that any specific host may become
|
||||
unreachable to a client should a server fail, a path fail, or the
|
||||
route to that host be withdrawn. These error conditions are,
|
||||
however, not specific to shared-unicast distributions, but would
|
||||
occur for standard unicast hosts.
|
||||
|
||||
Since ICMP response packets might go to a different member of the
|
||||
mesh than that sending a packet, packets sent with a shared unicast
|
||||
source address should also avoid using path MTU discovery.
|
||||
|
||||
Appendix A. contains an ASCII diagram of an example of a simple
|
||||
implementation of this system. In it, the odd numbered routers
|
||||
deliver traffic to the shared-unicast interface network and filter
|
||||
traffic from the administrative network; the even numbered routers
|
||||
|
||||
|
||||
|
||||
Hardie Informational [Page 4]
|
||||
|
||||
RFC 3258 Distributing Authoritative Name Servers April 2002
|
||||
|
||||
|
||||
deliver traffic to the administrative network and filter traffic from
|
||||
the shared-unicast network. These are depicted as separate routers
|
||||
for the ease this gives in explanation, but they could easily be
|
||||
separate interfaces on the same router. Similarly, a local NTP
|
||||
source is depicted for synchronization, but the level of
|
||||
synchronization needed would not require that source to be either
|
||||
local or a stratum one NTP server.
|
||||
|
||||
3. Administration
|
||||
|
||||
3.1 Points of Contact
|
||||
|
||||
A single point of contact for reporting problems is crucial to the
|
||||
correct administration of this system. If an external user of the
|
||||
system needs to report a problem related to the service, there must
|
||||
be no ambiguity about whom to contact. If internal monitoring does
|
||||
not indicate a problem, the contact may, of course, need to work with
|
||||
the external user to identify which server generated the error.
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
As a core piece of Internet infrastructure, authoritative name
|
||||
servers are common targets of attack. The practices outlined here
|
||||
increase the risk of certain kinds of attacks and reduce the risk of
|
||||
others.
|
||||
|
||||
4.1 Increased Risks
|
||||
|
||||
4.1.1 Increase in physical servers
|
||||
|
||||
The architecture outlined in this document increases the number of
|
||||
physical servers, which could increase the possibility that a server
|
||||
mis-configuration will occur which allows for a security breach. In
|
||||
general, the entity administering a mesh should ensure that patches
|
||||
and security mechanisms applied to a single member of the mesh are
|
||||
appropriate for and applied to all of the members of a mesh.
|
||||
"Genetic diversity" (code from different code bases) can be a useful
|
||||
security measure in avoiding attacks based on vulnerabilities in a
|
||||
specific code base; in order to ensure consistency of responses from
|
||||
a single named server, however, that diversity should be applied to
|
||||
different shared-unicast meshes or between a mesh and a related
|
||||
unicast authoritative server.
|
||||
|
||||
4.1.2 Data synchronization problems
|
||||
|
||||
The level of systemic synchronization described above should be
|
||||
augmented by synchronization of the data present at each of the
|
||||
servers. While the DNS itself is a loosely coupled system, debugging
|
||||
|
||||
|
||||
|
||||
Hardie Informational [Page 5]
|
||||
|
||||
RFC 3258 Distributing Authoritative Name Servers April 2002
|
||||
|
||||
|
||||
problems with data in specific zones would be far more difficult if
|
||||
two different servers sharing a single unicast address might return
|
||||
different responses to the same query. For example, if the data
|
||||
associated with www.example.com has changed and the administrators of
|
||||
the domain are testing for the changes at the example.com
|
||||
authoritative name servers, they should not need to check each
|
||||
instance of a named authoritative server. The use of NTP to provide
|
||||
a synchronized time for switch-over eliminates some aspects of this
|
||||
problem, but mechanisms to handle failure during the switchover are
|
||||
required. In particular, a server which cannot make the switchover
|
||||
must not roll-back to a previous version; it must cease to respond to
|
||||
queries so that other servers are queried.
|
||||
|
||||
4.1.3 Distribution risks
|
||||
|
||||
If the mechanism used to distribute zone files among the servers is
|
||||
not well secured, a man-in-the-middle attack could result in the
|
||||
injection of false information. Digital signatures will alleviate
|
||||
this risk, but encrypted transport and tight access lists are a
|
||||
necessary adjunct to them. Since zone files will be distributed to
|
||||
the administrative interfaces of meshed servers, the access control
|
||||
list for distribution of the zone files should include the
|
||||
administrative interface of the server or servers, rather than their
|
||||
shared unicast addresses.
|
||||
|
||||
4.2 Decreased Risks
|
||||
|
||||
The increase in number of physical servers reduces the likelihood
|
||||
that a denial-of-service attack will take out a significant portion
|
||||
of the DNS infrastructure. The increase in servers also reduces the
|
||||
effect of machine crashes, fiber cuts, and localized disasters by
|
||||
reducing the number of users dependent on a specific machine.
|
||||
|
||||
5. Acknowledgments
|
||||
|
||||
Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
|
||||
Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato,
|
||||
Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all
|
||||
provided input and commentary on this work. The editor wishes to
|
||||
remember in particular the contribution of the late Scott Tucker,
|
||||
whose extensive systems experience and plain common sense both
|
||||
contributed greatly to the editor's own deployment experience and are
|
||||
missed by all who knew him.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardie Informational [Page 6]
|
||||
|
||||
RFC 3258 Distributing Authoritative Name Servers April 2002
|
||||
|
||||
|
||||
6. References
|
||||
|
||||
[SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
|
||||
and Operation of Secondary DNS Servers", BCP 16, RFC
|
||||
2182, July 1997.
|
||||
|
||||
[ROOT] Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
|
||||
Name Server Operational Requirements", BCP 40, RFC 2870,
|
||||
June 2000.
|
||||
|
||||
[ANYCAST] Patridge, C., Mendez, T. and W. Milliken, "Host
|
||||
Anycasting Service", RFC 1546, November 1993.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardie Informational [Page 7]
|
||||
|
||||
RFC 3258 Distributing Authoritative Name Servers April 2002
|
||||
|
||||
|
||||
Appendix A.
|
||||
|
||||
__________________
|
||||
Peer 1-| |
|
||||
Peer 2-| |
|
||||
Peer 3-| Switch |
|
||||
Transit| | _________ _________
|
||||
etc | |--|Router1|---|----|----------|Router2|---WAN-|
|
||||
| | --------- | | --------- |
|
||||
| | | | |
|
||||
| | | | |
|
||||
------------------ [NTP] [DNS] |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
__________________ |
|
||||
Peer 1-| | |
|
||||
Peer 2-| | |
|
||||
Peer 3-| Switch | |
|
||||
Transit| | _________ _________ |
|
||||
etc | |--|Router3|---|----|----------|Router4|---WAN-|
|
||||
| | --------- | | --------- |
|
||||
| | | | |
|
||||
| | | | |
|
||||
------------------ [NTP] [DNS] |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
__________________ |
|
||||
Peer 1-| | |
|
||||
Peer 2-| | |
|
||||
Peer 3-| Switch | |
|
||||
Transit| | _________ _________ |
|
||||
etc | |--|Router5|---|----|----------|Router6|---WAN-|
|
||||
| | --------- | | --------- |
|
||||
| | | | |
|
||||
| | | | |
|
||||
------------------ [NTP] [DNS] |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardie Informational [Page 8]
|
||||
|
||||
RFC 3258 Distributing Authoritative Name Servers April 2002
|
||||
|
||||
|
||||
|
|
||||
__________________ |
|
||||
Peer 1-| | |
|
||||
Peer 2-| | |
|
||||
Peer 3-| Switch | |
|
||||
Transit| | _________ _________ |
|
||||
etc | |--|Router7|---|----|----------|Router8|---WAN-|
|
||||
| | --------- | | ---------
|
||||
| | | |
|
||||
| | | |
|
||||
------------------ [NTP] [DNS]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardie Informational [Page 9]
|
||||
|
||||
RFC 3258 Distributing Authoritative Name Servers April 2002
|
||||
|
||||
|
||||
7. Editor's Address
|
||||
|
||||
Ted Hardie
|
||||
Nominum, Inc.
|
||||
2385 Bay Road.
|
||||
Redwood City, CA 94063
|
||||
|
||||
Phone: 1.650.381.6226
|
||||
EMail: Ted.Hardie@nominum.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardie Informational [Page 10]
|
||||
|
||||
RFC 3258 Distributing Authoritative Name Servers April 2002
|
||||
|
||||
|
||||
8. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
||||
|
||||
This document and translations of it may be copied and furnished to
|
||||
others, and derivative works that comment on or otherwise explain it
|
||||
or assist in its implementation may be prepared, copied, published
|
||||
and distributed, in whole or in part, without restriction of any
|
||||
kind, provided that the above copyright notice and this paragraph are
|
||||
included on all such copies and derivative works. However, this
|
||||
document itself may not be modified in any way, such as by removing
|
||||
the copyright notice or references to the Internet Society or other
|
||||
Internet organizations, except as needed for the purpose of
|
||||
developing Internet standards in which case the procedures for
|
||||
copyrights defined in the Internet Standards process must be
|
||||
followed, or as required to translate it into languages other than
|
||||
English.
|
||||
|
||||
The limited permissions granted above are perpetual and will not be
|
||||
revoked by the Internet Society or its successors or assigns.
|
||||
|
||||
This document and the information contained herein is provided on an
|
||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardie Informational [Page 11]
|
||||
|
||||
Reference in New Issue
Block a user