| IETF DNS Extensions Working Group Draft Specifications |
| These are not RFCs; they are works-in-process
which represent new features being considered.
Boldface indicates drafts which can be expected to proceed to
RFC "PROPOSED STANDARD" status.
|
| DNS Zone Transfer Protocol Clarifications
Summary
In the Domain Name System, zone data is replicated among authoritative
DNS servers by means of the 'zone transfer' protocol, also known as the
'AXFR' protocol. This memo clarifies, updates, and adds missing detail
to the original AXFR protocol specification in RFC1034.
|
Mar-2002 |
| GSS Algorithm for TSIG (GSS-TSIG)
Summary
The TSIG protocol provides transaction level authentication for
DNS. TSIG is extensible through the definition of new algorithms.
This document specifies an algorithm based on the Generic Security
Service Application Program Interface (GSS-API) (RFC2743).
|
Feb-2002 |
| DNS Security Document Roadmap
Summary
DNS Security (DNSSEC) technology is composed of extensions to the Domain
Name System (DNS) protocol that provide data integrity
and authentication to security aware resolvers and applications
through the use of cryptographic digital signatures. Several documents
exist to describe these extensions and the implementation-specific
details regarding specific digital signing schemes. The
interrelationship between these different documents is discussed here. A
brief overview of what to find in which document and author guidelines
for what to include in new DNS Security documents, or revisions
to existing documents, is described.
|
Nov-2001 |
| Applicability Statement for DNS MIB Extensions
Summary
More than six years after the DNS Server and Resolver MIB
extensions became proposed standards, there still has not been any
significant deployment of these MIB extensions. This note examines the
reasons why these MIB extensions were never deployed, and recommends
retiring these MIB extensions by moving them to Historical status.
|
Oct-2000 |
| Link-Local Multicast Name Resolution (LLMNR)
Summary
Today, with the rise of home networking, there are an increasing
number of ad-hoc networks operating without a DNS server. In order to
allow name resolution in such environments, Link-Local Multicast
Name Resolution (LLMNR) is proposed.
|
Jul-2002 |
| Redefinition of DNS AD bit
Summary
Based on implementation experience, the current definition of the 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.
|
Jun-2002 |
| Obsoleting IQUERY
Summary
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 PTR queries and reverse-mapping
records is preferable. Consequently, this document deprecates the IQUERY
operation and updates RFC 1035 to declare it entirely obsolete.
|
Jul-2002 |
| Delegation Signer Resource Record
Summary
The delegation signer (DS) resource record is inserted at a zone
cut (i.e., a delegation point) to indicate that the delegated zone
is digitally signed and that the delegated zone recognizes the
indicated key as a valid zone key for the delegated zone.
|
Jun-2002 |
| Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
Summary
A standard method for storing Diffie-Hellman keys in the Domain
Name System is described which utilizes DNS KEY resource records.
|
May-2002 |
| DSA KEYs and SIGs in the Domain Name System (DNS)
Summary
A standard method for storing US Government Digital Signature Algorithm
keys and signatures in the Domain Name System is described which
utilizes DNS KEY and SIG resource records.
|
May-2002 |
| Tradeoffs in DNS support for IPv6
Summary
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.
|
Jun-2002 |
| Elliptic Curve KEYs in the DNS
Summary
A standard method for storing elliptic curve cryptographic keys in the
Domain Name System is described which utilizes DNS KEY resource record.
|
Mar-2002 |
| DNS Security Introduction and Requirements
Summary
The Domain Name System Security Extensions (DNSSEC) provide data origin
authentication and data integrity. This document introduces these
extensions and describes their capabilities and limitations. The
services that the security extensions provide and do not provide are
discussed. Lastly, the group of documents that describe the DNS security
extensions and their interrelationships is discussed.
|
Jul-2002 |
| Representing IPv6 addresses in DNS
Summary
This document clarifies and updates the standards status of RFCs
that define direct and reverse map of IPv6 addresses in DNS. This
document moves the A6 and Bit label specifications to experimental
status.
|
Jun-2002 |
| TKEY Secret Key Renewal Mode
Summary
This document defines a new mode in TKEY [RFC2930] and proposes
anatomic method for changing secret keys used for TSIG
[RFC2845] periodically. Originally, TKEY provides methods of setting up
shared secrets other than manual exchange, but it cannot control timing
ofkey renewal very well though it can add or delete shared
keys separately. This proposal is a systematical key renewal
procedure intended for preventing signing DNS messages with old and
non-safekeys permanently.
|
May-2002 |
| Limiting the Scope of the KEY Resource Record
Summary
This document limits the Domain Name System KEY resource record to only
keys used by the Domain Name System Security Extensions (DNSSEC). The
original KEY resource record used sub-typing to store both DNSSEC keys
and arbitrary application keys. Storing both DNSSEC and application keys
in one record was a mistake. This document removes application keys
from the KEY record by redefining the Protocol Octet field inthe KEY
Resource Record Data. As a result of removing application keys, all but
one of the flags in the KEY record become unnecessary and are removed.
Three existing application key sub-types are changed to reserved, but
the format ofthe KEY record is not changed. This document updates
RFC2535.
|
Jun-2002 |
| Threat Analysis Of The Domain Name System
Summary
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.
|
Feb-2002 |
| Resource Records for DNS Security Extensions
Summary
The DNS Security Extensions (DNSSEC) introduce four resource
records: the KEY, DS, SIG, and NXT resource records. This document
defines the purpose and the RDATA format for each of these records.
This document is part of a family of documents that describe the
DNS Security Extensions (DNSSEC).
|
Feb-2002 |
| The DISCOVER opcode
Summary
The QUERY opcode in the DNS is designed for unicast. With
the development of multicast capabilities in the DNS, it is desireable to
have a more robust opcode for server interactions since a single request
may result in replies from multiple responders. So DISCOVER is defined
to deal with replies from multiple responders. As such, this document
extend the core DNS specifications to allowclients to have a method for
coping with replies from multiple responders. Use of this new opcode may
facilitate DNS operations in modern networking topologies. A prototype
of the DISCOVER opcode was developed as part of the TBDS project, funded
under DARPA grant F30602-99-1-0523.
|
Apr-2002 |
|
| IETF Domain Name Server Operations (dnsop) |
| Requiring DNS IN-ADDR Mapping
Summary
Mapping of addresses to names has been a feature of DNS. Many
sites, implement it, many others don't. Some applications attempt to use
it as a part of a security strategy. The goal of this document is
to encourage proper deployment of address to name mappings, and
provide guidance for their use.
|
Mar-2002 |
| IP Addresses that should never appear in the public DNS
Summary
This document specifies an Internet Best Current Practice for
the Internet Community. It has two themes. Firstly, it reinforces
the prohibition in [RFC 1918] about the appearance of private
IP addresses in publicly visible DNS records, and extends the discussion
to include IPv6 addresses.
|
Feb-2002 |
| IPv4-to-IPv6 migration and DNS name space fragmentation
Summary
This memo documents some problems forseen in transitioning from
a IPv4-only DNS hierarchy via a long period of mixture to an IPv6-mostly
situation sometime in the future. The mixture period is expected to be
very long, and hence design choices should very much take this into
account, rather than just regard the transition as a relatively short
period of pain.
|
Mar-2002 |
| Identifying an Authoritative Name Server
Summary
A standardized mechanism to determine the identity of a name
server responding to a particular query would be useful, particularly as
a diagnostic aid. This document describes an identification
convention used in one widely deployed implementation of the DNS
protocol and proposes a slight modification to that convention aimed at
addressing some implementation concerns.
|
May-2002 |
| Miscellaneous IETF DNS WG Drafts |
| Well known site local unicast addresses for DNS resolver
Summary
This documents specifies a method for nodes to find a DNS resolver with
minimum configuration in the network and without running a discovery
protocol on the nodes.
|
Jun-2002 |
| Role of the Domain Name System
Summary
The original function and purpose of the DNS is reviewed, and contrasted
with some of the functions into which it is being forced today and some
of the newer demands being placed upon it or suggested for it. A
framework for an alternative to placing these additional stresses on the
DNS is then outlined. This document and that framework are not a
proposed solution, only a strong suggestion that the time has come to
begin thinking more broadly about the problems we are encountering and
possible approaches to solving them.
|
Jun-2002 |
| Domain Name System URI Scheme and MIME Media Types
Summary
This draft describes a URI scheme for DNS resources and MIME media
types for DNS data.
|
May-2002 |
| A Search-based access model for the DNS
Summary
This memo discusses strategies for supporting 'DNS searching' finding
of names in the DNS, or references that will ultimately point to DNS
names, by a mechanism layered above the DNS itself that permits fuzzy
matching, selection that uses attributes or facets, and use of
descriptive terms.
|
Jun-2002 |
| Using DNS for VPN Discovery
Summary
Virtual private networks are becoming a common service offered by
service providers. There are many technologies over which to implement
a VPN service, ranging from IPSec to GRE to MPLS. A common requirement
of the VPN methodologies is the need to discover all of the sites, or
at least all the provider equipment associated with the sites, that are
in a particular VPN. DNS provides a simple and commonly available means
for site discovery that is independent of any signaling protocol.
|
Mar-2002 |
| DNS RR type for NAI
Summary
This document proposes the use of the new DNS RR type 'NAI' (Network
Access Identifier) [RFC2486] to specify dynamically assigned IP address
|
Mar-2002 |
| Authoritative Mail Sender DNS Resource Record
Summary
This document defines a new experimental DNS resource record
type, Authoritative Mail Sender (MS), which can be used to verify
the authenticity of the domain name provided in the sender address of
a mail message and help to prevent forgery of sender addresses.
|
Aug-2002 |
| Extensible Provisioning Protocol DNS Security Extensions Mapping
Summary
This document describes an Extensible Provisioning Protocol
(EPP) extension mapping for the provisioning and management of DNS
security extensions for domain names stored in a shared central
repository. Specified in XML, this mapping extends the EPP domain name
mapping to provide additional features required for the provisioning of
DNSsecurity extensions.
|
June-2002 |
| Discussing Application Public Keys in the DNS
Summary
A debate over whether to include public keys for other applications
in the Domain Name System has been held ever since the introduction of
the DNS Security Extensions. This document records the salient points
of the debate.
|
Feb-2002 |
| ENUM Root Domain
Summary
RFC 2916 specifies that the domain e164.arpa is the rootdomain for the
DNS storage for NAPTR records for ENUMs.This document proposes that the
root domain referenced inRFC 2916 be changed from e164.arpa to a
generic domain, suchas e164.foo. This would give developers of ENUM
applications a greater degree of flexibility in configuring
DNS structures for ENUM.
|
Feb-2002 |
| A Private DNS Namespace for Automatic Configuration
Summary
This memo defines a locally scoped private DNS namespace. Such
a namespace supports self-configured authoritative nameservers in home or
zeroconf environments where global names for devices are not required,
yet local name resolution is beneficial.
|
Jul-2002 |
| Root Fix for the .US Top Level Domain
Summary
This document describes the 'Root Fix for the .US Top Level Domain'.
Root Fix is a series of actions taken by the Open Root Server
Confederation (ORSC) to prevent the destabilization of the DNS due to
ICANN's introduction of colliding top level domains. This document
describes the actions taken bythe ORSC to remedy the collateral damage
that has been directly caused to the .US top level domain in non-ICANN
root systems.
|
Mar-2002 |
| MCI (Multicast Channel Identifier) DNS RR type for the support of SSM (Source Specific Multicast)
Summary
This document proposes the use of the new DNS RR type MCI (Multicast
Channel Identifier), as it is specifying SSM (Source Specific
Multicast) multicast channel [SSM] as a DNS Resource Record. It shall
allow the advance multicast session advertisement by providing the
dynamic mapping between SSM multicast channel and MCI.
|
Mar-2002 |
| Chinese Name String in Search-based access model for the DNS
Summary
There are many requirements of developing internationalized and
human-readable Internet identifiers/names now, thereby there are many
systems based on DNS technology to meet such requirements. John C.
Klensin has proposed a three-layer search-based access model for the
DNS [DNSSEARCH]; this paper is only to explain some related problems
mentioned in John C. Klensin's proposal. Especially it focuses on
Traditional and Simplified Chinese problems and some other special
Chinese requirements. The ultimate goal for any kinds of search-based
access system is to help users to access network resources in more
natural ways, which have different meaning for different user groups.
On the premise of respecting Chinese user's language convention, it is
very important for a valuable and human-friendly system to deal with
traditional and simplified Chinese equivalence problems.
|
May-2002 |
| DNS/L2TP Based VPLS
Summary
This memo describes a simple mechanism to implement provider provisioned
Virtual Private LAN Service (VPLS) using DNS and L2TP as control and
data plane protocols.
|
June-2002 |
| ROOT ZONE PROTOCOL
Summary
The changing structure and size of today's Internet has taxed the
existing name services and their architecture to the breaking point.
The DNS system of today was unfortunately architected to have a single
root zone and limited set of Top Level Domains. This is defined usually
in the set of root servers any resolving request uses to lookup an
address. This proposal then is an attempt to lessen the impact on
end-users and registrars and to allow IP owners a greater freedom in
representing namespace to their customers. The elevator description is
that this I-D proposes the restructuring of domain names more fully
along the lines of a telephone number by creating a ROOT ZONE PROTOCOL
as an addition to multiply the existing DNS services times the number
of ROOT ZONES.
|
June-2002 |
| A DNS RR for Pointers to RRs outside class IN
Summary
The Domain Name System is a global distributed lookup system
with delegation. In the original specification of the DNS [RFC 1035],
CLASSes were described as parallel data structures within a
single namespace but with potentially different delegations of
authority.[BCP 42] defines a different vision, in which different
CLASSes represent fundamentally different namespaces. Though [BCP 42]
includes procedures for assignment of CLASSes, there has been little
use of this axis of extensibility; in practice, CLASS IN is the only
widely deployed CLASS in the DNS. The ubiquity of CLASS IN for name to
IP address mapping has caused a vicious cycle in which extensions are
placed within that CLASS to take advantage of its global deployment,
with each addition further increasing its gravitational attraction. This
document describes a ResourceRecord for use within CLASS IN that
contains a pointer to a CLASS outside of IN. This mechanism is intended
to allow administratorsto indicate that a named resource identified
within CLASS IN is also present in a different namespace, potentially
under a different name. This cross-class pointer will allow the DNS to
handle new namespaces with mechanisms appropriate to those
namespaces while providing a connection to the globally deployed CLASS
IN namespace.
|
June-2002 |
