A DNS Resource Record for Confidential Comments (NOTE RR)ISC950 Charter StRedwood CityCA94063USAeach@isc.orgISC950 Charter StRedwood CityCA94063USAdmahoney@isc.org
General
DNSRRcommentsnote
While the DNS zone master file format has always allowed comments,
there is no existing mechanism to preserve comments once the
zone has been loaded into memory or converted to a binary
representation. This note proposes a new "NOTE" RR type, which
is stored alongside zone data and may be included in zone
transfers, but is not returned in response to DNS queries.
DNS zone master files, as specified in [RFC 1035], can include
comment text: any text on a line following an unquoted semicolon is
ignored. Once the zone has been loaded, however, these comments can
be lost. Servers which dump backup copies of dynamically updated or
automatically signed zones may obliterate comments that were in the
original zone files; slave servers do not receive comment text when
transferring zones from master servers.
Comments can be stored in the zone as TXT RRs, which are backed up
and preserved across across zone transfers, but TXT records are
available to any DNS query. Because zone file comments commonly
include information about internal networks and/or personnel that
could be of use to potential attackers, it is better for
distribution of comment data to be restricted.
This document proposes a mechanism to store confidential comments
within zone data. The presence/absence and the content of comments
are concealed from normal DNS queries (except from specific trusted
DNS clients), as well as from slave servers that do not explicitly
signal their ability to cooperate with these restrictions.
A "NOTE" RR can be used to store a comment at a DNS node.
It may be transferred to slaves or written to permanent storage, but
it is not returned in response to normal DNS queries.
A "NOTE OK" EDNS flag
signals that the sender understands NOTE records and will restrict
their dissemination. If this flag is not set in a zone transfer
request, NOTE data will be omitted from the zone transfer.
Traditional zone file comments, indicated by semicolons, are still
ignored.
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
.
The NOTE RR is defined for all classes, with mnemonic NOTE and type
code [TBD]. The RDATA and presentation formats are identical to
those of the TXT RR defined in , e.g:
A slave transferring a zone from a master server must explicitly
signal its understanding of the NOTE RR. The mechanism for this is a
flag allocated from the most significant bit of the Z field in the
EDNS0 OPT header. This is referred to as the "NOTE OK"
(NO) bit.
Setting the NO bit in a query of type AXFR or IXFR signals that the
sender has implemented the NOTE RR and is able to restrict access to
NOTE data as specified in Section 4. If the bit is not set, the
server MUST omit NOTE records from the zone transfer.
Setting the NO bit in a query of type NOTE or type ANY signals that
the sender is not a recursive or forwarding resolver and will not
cache the response. If and only if the sender is explicitly trusted
to receive NOTE data, the server MAY respond. If the bit is not set,
the server MUST respond as if NOTE data did not exist.
(If allocation of a flag from the Z field is problematic, the
signaling functionality of the NO bit could also be implemented with
a zero-length EDNS option, at the cost of an additional 4 octets in
the query.)
Because zone file comments often contain information which may be
security-sensitive or otherwise not for public consumption,
authoritative servers implementing the NOTE RR type MUST implement
the restrictions described below:
NOTE RRs MUST NOT be returned in response to any DNS query,
including zone transfer requests, unless the NO bit is set.
The NOTE RRset TTL MUST be zero. Any configured TTL greater than
zero is overridden.
NOTE RRs MUST be omitted from responses to queries of type ANY.
(This MAY be relaxed if the client is explicitly trusted with
NOTE data and the NO bit is set in the query.)
When an explicit query for type NOTE is received, the server
MUST return NXDOMAIN or NOERROR/NODATA, depending on the
presence or absence of other data at the node. (This MAY be
relaxed if the client is explicitly trusted with NOTE data and
the NO bit is set in the query.)
Where and as noted, these requirements MAY be relaxed, if and only
if a separately-configurable access control mechanism is available
so that NOTE records are visible only to a restricted set of
explicitly trusted clients (i.e., queries originating from a
particular IP address range or signed by a specific TSIG key, and
with the NO bit set), and hidden from all other clients. The default
setting of such a mechanism, and the behavior of any server not
implementing such a mechanism, MUST be to hide NOTE data from all
clients.
Recursive resolvers MUST NOT set the NO bit when sending iterative
queries to satisfy recursive client queries.
In addition, resolvers SHOULD implement the following restrictions:
NOTE RRs MUST NOT be cached; a TTL greater than zero MUST be
ignored.
Recursive queries for type NOTE MUST be answered as if the data
did not exist.
Resolvers SHOULD NOT iterate for type NOTE except to determine
whether the correct response code is NXDOMAIN or NOERROR.
In order to preserve the fiction that NOTE RRs do not exist for
untrusted clients, some changes are needed with respect to DNSSEC
signing and query logic :
NOTE RRsets MAY be left unsigned.
If NOTE RRsets are signed, then the covering RRSIG RRsets MUST
be hidden from untrusted clients just as the NOTE RRsets are. If
a NOTE RRset at an otherwise empty node is signed, the server
MUST respond with NXDOMAIN to a query of type NOTE or type ANY,
in spite of the presence of an RRSIG RRset at that node. RRSIG
RRsets covering type NOTE MUST be omitted from responses to
queries of type ANY or type RRSIG, and from responses to queries
of type AXFR or IXFR when the NO bit is not set. RRSIG RRsets
covering type NOTE MUST have TTL zero.
Nodes containing NOTE RRs but no other data SHOULD be omitted
from NSEC RR chains and MAY be
omitted from NSEC3 RR chains.
The NOTE RR type MUST NOT be included in the Type Bit Map field
of an NSEC or NSEC3 RR.
NOTE RRs MAY be submitted via UPDATE
. Servers SHOULD ignore prerequisites
that specify type NOTE, in order to conceal from untrusted clients
the presence or absence of NOTE RRs.
It is an explicit design goal that NOTE data should not be
accessible via normal DNS queries, because zone file comments
commonly include information that could be of use to potential
attackers.
Operators using NOTE RRs in their zones SHOULD disallow zone
transfers except to trusted slave servers. Authoritative servers MAY
refuse to load or serve NOTE data if zone transfers are not
restricted.
IANA is requested to take the actions in this section.
This document requests the allocation of a DNS RR type number for
the NOTE RR type.
EDNS(0) defines 16 bits, encoded
into the TTL field of the OPT record, as extended flags. 15 of
these flags remain undefined. This document requests that one of
these be allocated. The OPT header would then be:
Thanks to Paul Vixie, Stephen Morris, Chuck Aurora, and Jeremy Reed
for suggestions and feedback.
Domain names - implementation and specificationUSC/ISI4676 Admiralty WayMarina del ReyCA90291US+1 213 822 1511Dynamic Updates in the Domain Name System (DNS UPDATE)Internet Software ConsortiumStar Route Box 159AWoodsideCA 94062+1 415 747 0204paul@vix.comBellcore445 South StreetMorristownNJ 07960+1 201 829 4514set@thumper.bellcore.comCisco Systems170 West Tasman DriveSan JoseCA 95134-1706+1 914 528 0090yakov@cisco.comDigital Equipment Corp.110 Spitbrook Rd ZK3-3/U14NashuaNH 03062-2698+1 603 881 0400bound@zk3.dec.com
Applications
domain namedomain name system
The Domain Name System was originally designed to support queries of
a statically configured database. While the data was expected to
change, the frequency of those changes was expected to be fairly low,
and all updates were made as external edits to a zone's Master File.
Using this specification of the UPDATE opcode, it is possible to add
or delete RRs or RRsets from a specified zone. Prerequisites are
specified separately from update operations, and can specify a
dependency upon either the previous existence or nonexistence of an
RRset, or the existence of a single RR.
UPDATE is atomic, i.e., all prerequisites must be satisfied or else
no update operations will take place. There are no data dependent
error conditions defined after the prerequisites have been met.
DNS Security (DNSSEC) NextSECure (NSEC) RDATA FormatThis document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space. [STANDARDS-TRACK]DNS Security (DNSSEC) Hashed Authenticated Denial of ExistenceThe 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. [STANDARDS-TRACK]Extension Mechanisms for DNS (EDNS(0))Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Protocol Modifications for the DNS Security ExtensionsThis 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.</t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]