|
|
|
|
|
|
|
|
|
|
| Last Update: Aug 24, 2010
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2845
05/2000
(15 p.)
pdf(2p)
|
P. Vixie
O. Gudmundsson
D. Eastlake
B. Wellington |
|
Secret Key Transaction Authentication for DNS (TSIG) |
This protocol allows for transaction level authentication using
shared secrets and one way hashing. It can be used to authenticate
dynamic updates as coming from an approved client, or to authenticate
responses as coming from an approved recursive name server.
No provision has been made here for distributing the shared secrets;
it is expected that a network administrator will statically configure
name servers and clients using some out of band mechanism such as
sneaker-net until a secure automated mechanism for key distribution
is available.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2930
09/2000
(16 p.)
pdf(2p)
|
D. Eastlake
|
|
Secret Key Establishment for DNS (TKEY RR) |
|
[RFC 2845] provides a means of authenticating Domain Name System
(DNS) queries and responses using shared secret keys via the
Transaction Signature (TSIG) resource record (RR). However, it
provides no mechanism for setting up such keys other than manual
exchange. This document describes a Transaction Key (TKEY) RR that
can be used in a number of different modes to establish shared secret
keys between a DNS resolver and server.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2931
09/2000
(10 p.)
pdf(2p)
|
D. Eastlake
|
|
DNS Request and Transaction Signatures ( SIG(0)s ) |
Extensions to the Domain Name System (DNS) are described in [RFC
2535] that can provide data origin and transaction integrity and
authentication to security aware resolvers and applications through
the use of cryptographic digital signatures.
Implementation experience has indicated the need for minor but non-
interoperable changes in Request and Transaction signature resource
records ( SIG(0)s ). These changes are documented herein.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3007
11/2000
(9 p.)
pdf(2p)
|
B. Wellington
|
|
Secure Domain Name System (DNS) Dynamic Update |
|
This document proposes a method for performing secure Domain Name
System (DNS) dynamic updates. The method described here is intended
to be flexible and useful while requiring as few changes to the
protocol as possible. The authentication of the dynamic update
message is separate from later DNSSEC validation of the data. Secure
communication based on authenticated requests and transactions is
used to provide authorization.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3110
05/2001
(7 p.)
pdf(2p)
|
D. Eastlake
|
|
RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) |
This document describes how to produce RSA/SHA1 SIG resource records
(RRs) in Section 3 and, so as to completely replace RFC 2537,
describes how to produce RSA KEY RRs in Section 2.
Since the adoption of a Proposed Standard for RSA signatures in the
DNS (Domain Name Space), advances in hashing have been made. A new
DNS signature algorithm is defined to make these advances available
in SIG RRs. The use of the previously specified weaker mechanism is
deprecated. The algorithm number of the RSA KEY RR is changed to
correspond to this new SIG algorithm. No other changes are made to
DNS security.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3123
06/2001
(8 p.)
pdf(2p)
|
P. Koch
|
|
A DNS RR Type for Lists of Address Prefixes (APL RR) |
|
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.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3197
11/2001
(5 p.)
pdf(2p)
|
R. Austein
|
|
Applicability Statement for DNS MIB Extensions |
|
This document explains why, after more than six years as proposed
standards, the DNS Server and Resolver MIB extensions were never
deployed, and recommends retiring these MIB extensions by moving them
to Historical status.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC3225
12/2001
(6 p.)
pdf(2p)
|
D. Conrad
|
|
Indicating Resolver Support of DNSSEC |
|
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.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3226
12/2001
(6 p.)
pdf(2p)
|
O. Gudmundsson
|
|
DNSSEC and IPv6 A6 aware server/resolver message size requirements |
|
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.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3363
08/2002
(6 p.)
pdf(2p)
|
R. Bush
A. Durand
B. Fink
O. Gudmundsson
T. Hain |
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC3364
08/2002
(11 p.)
pdf(2p)
|
R. Austein
|
|
Tradeoffs in Domain Name System (DNS) Support for IPv6 |
|
The IETF has two different proposals on the table for how to do DNS
support for IPv6, and has thus far failed to reach a clear consensus
on which approach is better. This note attempts to examine the pros
and cons of each approach, in the hope of clarifying the debate so
that we can reach closure and move on.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC3425
11/2002
(5 p.)
pdf(2p)
|
D. Lawrence
|
|
Obsoleting IQUERY |
|
The IQUERY method of performing inverse DNS lookups, specified in RFC
1035, has not been generally implemented and has usually been
operationally disabled where it has been implemented. Both reflect a
general view in the community that the concept was unwise and that
the widely-used alternate approach of using pointer (PTR) queries and
reverse-mapping records is preferable. Consequently, this document
deprecates the IQUERY operation, declaring it entirely obsolete.
This document updates RFC 1035.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3596
10/2003
(8 p.)
pdf(2p)
|
S. Thomson
C. Huitema
V. Ksinant
M. Souissi |
|
DNS Extensions to Support IP Version 6 |
|
This document defines the changes that need to be made to the Domain
Name System (DNS) to support hosts running IP version 6 (IPv6). The
changes include a resource record type to store an IPv6 address, a
domain to support lookups based on an IPv6 address, and updated
definitions of existing query types that return Internet addresses as
part of additional section processing. The extensions are designed
to be compatible with existing applications and, in particular, DNS
implementations themselves.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3597
09/2003
(8 p.)
pdf(2p)
|
A. Gustafsson
|
|
Handling of Unknown DNS Resource Record (RR) Types |
|
Extending the Domain Name System (DNS) with new Resource Record (RR)
types currently requires changes to name server software. This
document specifies the changes necessary to allow future DNS
implementations to handle new RR types transparently.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3645
10/2003
(26 p.)
pdf(2p)
|
S. Kwan
P. Garg
J. Gilroy
L. Esibov
J. Westhead
R. Hall |
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3833
08/2004
(16 p.)
pdf(2p)
|
D. Atkins
R. Austein
|
|
Threat Analysis of the Domain Name System (DNS) |
|
Although the DNS Security Extensions (DNSSEC) have been under
development for most of the last decade, the IETF has never written
down the specific set of threats against which DNSSEC is designed to
protect. Among other drawbacks, this cart-before-the-horse situation
has made it difficult to determine whether DNSSEC meets its design
goals, since its design goals are not well specified. This note
attempts to document some of the known threats to the DNS, and, in
doing so, attempts to measure to what extent (if any) DNSSEC is a
useful tool in defending against these threats.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC4033
03/2005
(21 p.)
pdf(2p)
|
R. Arends
R. Austein
M. Larson
D. Massey
S. Rose |
|
DNS Security Introduction and Requirements |
|
The Domain Name System Security Extensions (DNSSEC) add data origin
authentication and data integrity to the Domain Name System. This
document introduces these extensions and describes their capabilities
and limitations. This document also discusses the services that the
DNS security extensions do and do not provide. Last, this document
describes the interrelationships between the documents that
collectively describe DNSSEC.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4034
03/2005
(29 p.)
pdf(2p)
|
R. Arends
R. Austein
M. Larson
D. Massey
S. Rose |
|
Resource Records for the DNS Security Extensions |
This document is part of a family of documents that describe the DNS
Security Extensions (DNSSEC). The DNS Security Extensions are a
collection of resource records and protocol modifications that
provide source authentication for the DNS. This document defines the
public key (DNSKEY), delegation signer (DS), resource record digital
signature (RRSIG), and authenticated denial of existence (NSEC)
resource records. The purpose and format of each resource record is
described in detail, and an example of each resource record is given.
This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4035
03/2005
(53 p.)
pdf(2p)
|
R. Arends
R. Austein
M. Larson
D. Massey
S. Rose |
|
Protocol Modifications for the DNS Security Extensions |
This document is part of a family of documents that describe the DNS
Security Extensions (DNSSEC). The DNS Security Extensions are a
collection of new resource records and protocol modifications that
add data origin authentication and data integrity to the DNS. This
document describes the DNSSEC protocol modifications. This document
defines the concept of a signed zone, along with the requirements for
serving and resolving by using DNSSEC. These techniques allow a
security-aware resolver to authenticate both DNS resource records and
authoritative DNS error indications.
This document obsoletes RFC 2535 and incorporates changes from all
updates to RFC 2535.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4343
01/2006
(10 p.)
pdf(2p)
|
D. Eastlake
|
|
DNS Case Insensitivity Clarification |
|
Domain Name System (DNS) names are "case insensitive". This document
explains exactly what that means and provides a clear specification
of the rules. This clarification updates RFCs 1034, 1035, and 2181.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4398
03/2006
(17 p.)
pdf(2p)
|
S. Josefsson
|
|
Storing Certificates in the DNS |
|
Cryptographic public keys are frequently published, and their
authenticity is demonstrated by certificates. A CERT resource record
(RR) is defined so that such certificates and related certificate
revocation lists can be stored in the Domain Name System (DNS).
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4470
04/2006
(8 p.)
pdf(2p)
|
S. Weiler
J. Ihren
|
|
Minimally Covering NSEC Records and DNSSEC On-line Signing |
|
This document describes how to construct DNSSEC NSEC resource records
that cover a smaller range of names than called for by RFC 4034. By
generating and signing these records on demand, authoritative name
servers can effectively stop the disclosure of zone contents
otherwise made possible by walking the chain of NSEC records in a
signed zone.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4471
09/2006
(23 p.)
pdf(2p)
|
G. Sisson
B. Laurie
|
|
Derivation of DNS Name Predecessor and Successor |
|
This document describes two methods for deriving the canonically-
ordered predecessor and successor of a DNS name. These methods may
be used for dynamic NSEC resource record synthesis, enabling
security-aware name servers to provide authenticated denial of
existence without disclosing other owner names in a DNSSEC secured
zone.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4592
07/2006
(20 p.)
pdf(2p)
|
E. Lewis
|
|
The Role of Wildcards in the Domain Name System |
|
This is an update to the wildcard definition of RFC 1034. The
interaction with wildcards and CNAME is changed, an error condition
is removed, and the words defining some concepts central to wildcards
are changed. The overall goal is not to change wildcards, but to
refine the definition of RFC 1034.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4635
08/2006
(8 p.)
pdf(2p)
|
D. Eastlake
|
|
HMAC SHA TSIG Algorithm Identifiers |
|
Use of the Domain Name System TSIG resource record requires
specification of a cryptographic message authentication code.
Currently, identifiers have been specified only for HMAC MD5 (Hashed
Message Authentication Code, Message Digest 5) and GSS (Generic
Security Service) TSIG algorithms. This document standardizes
identifiers and implementation requirements for additional HMAC SHA
(Secure Hash Algorithm) TSIG algorithms and standardizes how to
specify and handle the truncation of HMAC values in TSIG.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4701
10/2006
(12 p.)
pdf(2p)
|
M. Stapp
T. Lemon
A. Gustafsson
|
|
A DNS Resource Record (RR) for Encoding
DHCP Information (DHCID RR) |
|
It is possible for Dynamic Host Configuration Protocol (DHCP) clients
to attempt to update the same DNS Fully Qualified Domain Name (FQDN)
or to update a DNS FQDN that has been added to the DNS for another
purpose as they obtain DHCP leases. Whether the DHCP server or the
clients themselves perform the DNS updates, conflicts can arise. To
resolve such conflicts, RFC 4703 proposes storing client identifiers
in the DNS to unambiguously associate domain names with the DHCP
clients to which they refer. This memo defines a distinct Resource
Record (RR) type for this purpose for use by DHCP clients and
servers: the "DHCID" RR.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4795
01/2007
(31 p.)
pdf(2p)
|
B. Aboba
D. Thaler
L. Esibov
|
|
Link-Local Multicast Name Resolution (LLMNR) |
|
The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
name resolution in scenarios in which conventional DNS name
resolution is not possible. LLMNR supports all current and future
DNS formats, types, and classes, while operating on a separate port
from DNS, and with a distinct resolver cache. Since LLMNR only
operates on the local link, it cannot be considered a substitute for
DNS.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC4955
07/2007
(7 p.)
pdf(2p)
|
D. Blacka
|
|
DNS Security (DNSSEC) Experiments |
|
This document describes a methodology for deploying alternate, non-
backwards-compatible, DNS Security (DNSSEC) methodologies in an
experimental fashion without disrupting the deployment of standard
DNSSEC.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4956
07/2007
(17 p.)
pdf(2p)
|
R. Arends
M. Kosters
D. Blacka
|
|
DNS Security (DNSSEC) Opt-In |
|
In the DNS security (DNSSEC) extensions, delegations to unsigned
subzones are cryptographically secured. Maintaining this
cryptography is not always practical or necessary. This document
describes an experimental "Opt-In" model that allows administrators
to omit this cryptography and manage the cost of adopting DNSSEC with
large zones.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4986
08/2007
(11 p.)
pdf(2p)
|
H. Eland
R. Mundy
S. Crocker
S. Krishnaswamy |
|
Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover |
|
Every DNS security-aware resolver must have at least one Trust Anchor
to use as the basis for validating responses from DNS signed zones.
For various reasons, most DNS security-aware resolvers are expected
to have several Trust Anchors. For some operations, manual
monitoring and updating of Trust Anchors may be feasible, but many
operations will require automated methods for updating Trust Anchors
in their security-aware resolvers. This document identifies the
requirements that must be met by an automated DNS Trust Anchor
rollover solution for security-aware DNS resolvers.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
| | |
RFC5001
08/2007
(11 p.)
pdf(2p)
|
R. Austein
|
|
DNS Name Server Identifier (NSID) Option |
|
With the increased use of DNS anycast, load balancing, and other
mechanisms allowing more than one DNS name server to share a single
IP address, it is sometimes difficult to tell which of a pool of name
servers has answered a particular query. While existing ad-hoc
mechanisms allow an operator to send follow-up queries when it is
necessary to debug such a configuration, the only completely reliable
way to obtain the identity of the name server that responded is to
have the name server include this information in the response itself.
This note defines a protocol extension to support this functionality.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5011
09/2007
(14 p.)
pdf(2p)
|
M. StJohns
|
|
Automated Updates of DNS Security (DNSSEC) Trust Anchors |
This document describes a means for automated, authenticated, and
authorized updating of DNSSEC "trust anchors". The method provides
protection against N-1 key compromises of N keys in the trust point
key set. Based on the trust established by the presence of a current
anchor, other anchors may be added at the same place in the
hierarchy, and, ultimately, supplant the existing anchor(s).
This mechanism will require changes to resolver management behavior
(but not resolver resolution behavior), and the addition of a single
flag bit to the DNSKEY record.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5155
02/2008
(53 p.)
pdf(2p)
|
B. Laurie
G. Sisson
R. Arends
D. Blacka |
|
DNS Security (DNSSEC) Hashed Authenticated Denial of Existence |
|
The Domain Name System Security (DNSSEC) Extensions introduced the
NSEC resource record (RR) for authenticated denial of existence.
This document introduces an alternative resource record, NSEC3, which
similarly provides authenticated denial of existence. However, it
also provides measures against zone enumeration and permits gradual
expansion of delegation-centric zones.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5395
11/2008
(17 p.)
pdf(2p)
|
D. Eastlake
|
|
DNS IANA Considerations |
|
Internet Assigned Number Authority (IANA) parameter assignment
considerations are specified for the allocation of Domain Name System
(DNS) resource record types, CLASSes, operation codes, error codes,
DNS protocol message header bits, and AFSDB resource record subtypes.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC5452
01/2009
(18 p.)
pdf(2p)
|
A. Hubert
R. van Mook
|
|
Measures for Making DNS More Resilient against Forged Answers |
The current Internet climate poses serious threats to the Domain Name
System. In the interim period before the DNS protocol can be secured
more fully, measures can already be taken to harden the DNS to make
'spoofing' a recursing nameserver many orders of magnitude harder.
Even a cryptographically secured DNS benefits from having the ability
to discard bogus responses quickly, as this potentially saves large
amounts of computation.
By describing certain behavior that has previously not been
standardized, this document sets out how to make the DNS more
resilient against accepting incorrect responses. This document
updates RFC 2181.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5936
06/2010
(29 p.)
pdf(2p)
|
E. Lewis
A. Hoenes |
|
DNS Zone Transfer Protocol (AXFR) |
The standard means within the Domain Name System protocol for
maintaining coherence among a zone's authoritative name servers
consists of three mechanisms. Authoritative Transfer (AXFR) is one
of the mechanisms and is defined in RFC 1034 and RFC 1035.
The definition of AXFR has proven insufficient in detail, thereby
forcing implementations intended to be compliant to make assumptions,
impeding interoperability. Yet today we have a satisfactory set of
implementations that do interoperate. This document is a new
definition of AXFR -- new in the sense that it records an accurate
definition of an interoperable AXFR mechanism.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
