< draft-hunt-note-rr-01.txt   draft-hunt-note-rr-02.txt >
Network Working Group E. Hunt DNSOP Working Group E. Hunt
Internet-Draft D. Mahoney Internet-Draft D. Mahoney
Intended status: Standards Track ISC Updates: 6195 (if approved) ISC
Expires: November 29, 2014 May 28, 2014 Intended status: Standards Track July 6, 2019
Expires: January 7, 2020
A DNS Resource Record for Confidential Comments (NOTE RR) A DNS Resource Record for Confidential Comments (NOTE RR)
draft-hunt-note-rr-01 draft-hunt-note-rr-02
Abstract Abstract
While the DNS zone master file format has always allowed comments, While the DNS zone master file format has always allowed comments,
there is no existing mechanism to preserve comments once the zone has there is no existing mechanism to preserve comments once the zone has
been loaded into memory or converted to a binary representation. been loaded into memory or converted to a binary representation.
This note proposes a new "NOTE" RR type, which is stored alongside This note proposes a new RR type "NOTE", to be allocated from the
zone data and may be included in zone transfers, but is not returned Covert-RR type range proposed in [I-D.krecicki-dns-covert], so that
in response to DNS queries. confidential comments can be stored alongside zone data, and included
in zone transfers when Covert semantics are supported by the
secondary.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 29, 2014. This Internet-Draft will expire on January 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. The NOTE RR Type . . . . . . . . . . . . . . . . . . . . . . . 3 2. The NOTE RR Type . . . . . . . . . . . . . . . . . . . . . . 3
3. The NOTE-OK Option . . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
4. Authoritative Server Behavior . . . . . . . . . . . . . . . . . 4 4. Security and Privacy Considerations . . . . . . . . . . . . . 3
5. Recursive Server Behavior . . . . . . . . . . . . . . . . . . . 5 5. Normative References . . . . . . . . . . . . . . . . . . . . 3
6. DNSSEC Signing Behavior . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
7. UPDATE Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9.1. NOTE RR Type Code . . . . . . . . . . . . . . . . . . . . . 6
9.2. NOTE-OK Option Code . . . . . . . . . . . . . . . . . . . . 6
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
DNS zone master files, as specified in [RFC1035], can include comment DNS zone master files may include comments: any text on a line
text: any text on a line following an unquoted semicolon is ignored. following an unquoted semicolon is ignored when parsing the file
Once the zone has been loaded, however, these comments can be lost. [RFC1034]. These comments are often used by administrators to keep
Servers which dump backup copies of dynamically updated or notes about the zone data; for example, the purpose of a particular
automatically signed zones may obliterate comments that were in the host, or the person responsible for maintaining it.
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 When the zone is loaded, however, comments may be lost. Servers
within zone data. The presence/absence and the content of comments which dump backup copies of dynamically updated or automatically
are concealed from normal DNS queries (except from specific trusted signed zones may obliterate comments that were in the original zone
DNS clients), as well as from slave servers that do not explicitly files. Secondary servers do not receive comment text when
signal their ability to cooperate with these restrictions. transferring zones from primary servers.
A "NOTE" RR can be used to store a comment at a DNS node. It may be Comments could be stored in the zone itself as TXT RRs; these would
transferred to slaves or written to permanent storage, but it is not be preserved after zone updates and across zone transfers. However,
returned in response to normal DNS queries. 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.
A "NOTE-OK" EDNS [RFC6891] option signals that the sender understands A Covert Resource Record, as described in [I-D.krecicki-dns-covert],
NOTE records and will restrict their dissemination. If this option could be used for the storage of private text information within zone
is not included in a zone transfer request, NOTE data will be omitted data itself. This data could be transferred from primary to
from the zone transfer. secondary servers when Covert semantics are supported, and but would
be concealed from normal DNS queries (except from specific trusted
DNS clients) and from secondary servers that do not signal their
support of Covert data transfer.
Traditional zone file comments, indicated by semicolons, are still This document proposes the allocation of a new RR type NOTE from the
ignored. Covert-RR type range for this purpose. Comments that the operator
wishes to be stored and transferred with zone data can be encoded as
NOTE records. Traditional zone file comments, indicated by
semicolons, would still be ignored.
1.1. Reserved Words 1.1. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. The NOTE RR Type 2. The NOTE RR Type
The NOTE RR is defined for all classes, with mnemonic NOTE and type The NOTE RR is defined for all classes, with mnemonic NOTE and type
code [TBD]. The RDATA and presentation formats are identical to code (TBD). The RDATA and presentation formats are identical to
those of the TXT RR defined in [RFC1035], e.g: those of the TXT RR defined in [RFC1035], e.g:
$ORIGIN example.com. $ORIGIN example.com.
joesbox 7200 IN A 198.51.100.42 joesbox 7200 IN A 192.0.2.42
7200 IN AAAA 2001:DB8:3F:B019::17 7200 IN AAAA 2001:DB8:3F:B019::17
0 IN NOTE "Desktop system for Joe Smith, x7889" 0 IN NOTE "Desktop system for Joe Smith, x7889"
3. The NOTE-OK Option The RR type code MUST be allocated from the Covert-RR type range, and
NOTE record data MUST be treated as Covert [I-D.krecicki-dns-covert].
A slave transferring a zone from a master server must explicitly
signal its understanding of the NOTE RR. The mechanism for this is
an EDNS option, with OPTION-CODE [TBD]. OPTION-LENGTH MUST be zero
and OPTION-DATA MUST be empty.
Including a NOTE-OK option in a query of type AXFR or type IXFR
signals that the zone transfer client has implemented the NOTE RR and
is able to restrict access to NOTE data as specified in Section 4.
If the option is not included, the server MUST omit NOTE records from
the zone transfer.
Including a NOTE-OK option in a query of type NOTE or type ANY
signals that the client is not a recursive or forwarding resolver and
will not cache or further distribute the response. If and only if
the client is explicitly authorized to receive NOTE data, the server
MAY respond. If the option is not included, the server MUST respond
as if NOTE data did not exist.
4. Authoritative Server Behavior
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:
o NOTE RRs MUST NOT be returned in response to any DNS query,
including zone transfer requests, unless the query contains a
NOTE-OK option.
o The NOTE RRset TTL MUST be zero. Any configured TTL greater than
zero is overridden.
o 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 query contains a NOTE-OK option.)
o 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 query contains
a NOTE-OK option.)
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 including a
NOTE-OK option), 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.
5. Recursive Server Behavior
Recursive resolvers MUST NOT send NOTE-OK when iterating to satisfy
recursive client queries.
In addition, resolvers SHOULD implement the following restrictions:
o NOTE RRs MUST NOT be cached; a TTL greater than zero MUST be
ignored.
o Recursive queries for type NOTE MUST be answered as if the data
did not exist.
o Resolvers SHOULD NOT iterate for type NOTE except to determine
whether the correct response code is NXDOMAIN or NOERROR.
6. DNSSEC Signing Behavior
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 [RFC4035]:
o NOTE RRsets MAY be left unsigned.
o 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 zone transfers and
query responses whenver NOTE RRsets would be. RRSIG RRsets
covering type NOTE MUST have TTL zero.
o Nodes containing NOTE RRs but no other data SHOULD be omitted from
NSEC [RFC4034] RR chains and MAY be omitted from NSEC3 [RFC5155]
RR chains.
o The NOTE RR type MUST NOT be included in the Type Bit Map field of
an NSEC or NSEC3 RR.
7. UPDATE Behavior
NOTE RRs MAY be submitted via UPDATE [RFC2136]. Servers SHOULD
ignore prerequisites that specify type NOTE, in order to conceal from
untrusted clients the presence or absence of NOTE RRs.
8. Security Considerations
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.
9. IANA Considerations
IANA is requested to take the actions in this section.
9.1. NOTE RR Type Code
This document requests the allocation of a DNS RR type number for the 3. IANA Considerations
NOTE RR type.
9.2. NOTE-OK Option Code IANA is requested to allocate a DNS RR type number from the Covert-RR
type range for the NOTE RR type.
This document requests the allocation of an EDNS(0) option code for 4. Security and Privacy Considerations
the NOTE-OK option.
10. Acknowledgments NOTE data should only be accessible via Covert DNS queries, because
zone file comments commonly include information that could be of use
to potential attackers. Failure to implement the restrictions
outlined in [I-D.krecicki-dns-covert] could allow leakage of
sensitive information.
Thanks to Paul Vixie, Stephen Morris, Chuck Aurora, Jeremy Reed and 5. Normative References
Nicholas Weaver, Doug Barton and Olafur Gudmundsson for suggestions
and feedback.
11. References [I-D.krecicki-dns-covert]
Krecicki, W., Hunt, E., and D. Mahoney, "Domain Name
System (DNS) Resource Record types for transferring covert
information from primary to secondaries", draft-krecicki-
dns-covert-00 (work in progress), July 2019.
11.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
11.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Rose, "Protocol Modifications for the DNS Security 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
Extensions", RFC 4035, March 2005. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses Authors' Addresses
Evan Hunt Evan Hunt
ISC ISC
950 Charter St 950 Charter St
Redwood City, CA 94063 Redwood City, CA 94063
USA US
Email: each@isc.org Email: each@isc.org
Dan Mahoney Dan Mahoney
ISC ISC
950 Charter St 950 Charter St
Redwood City, CA 94063 Redwood City, CA 94063
USA US
Email: dmahoney@isc.org Email: dmahoney@isc.org
 End of changes. 33 change blocks. 
214 lines changed or deleted 89 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/