A DNS Resource Record for Confidential Comments (NOTE RR)
draft-hunt-note-rr-00

Network Working Group                                            E. Hunt
Internet-Draft                                                D. Mahoney
Intended status: Standards Track                                     ISC
Expires: November 28, 2014                                  May 27, 2014

       A DNS Resource Record for Confidential Comments (NOTE RR)
                         draft-hunt-note-rr-00

Abstract

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on November 28, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as

Hunt & Mahoney          Expires November 28, 2014               [Page 1]
Internet-Draft                   note-rr                        May 2014

   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Reserved Words  . . . . . . . . . . . . . . . . . . . . . . 3
   2.  The NOTE RR Type  . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  The NOTE OK Flag  . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Authoritative Server Behavior . . . . . . . . . . . . . . . . . 4
   5.  Recursive Server Behavior . . . . . . . . . . . . . . . . . . . 5
   6.  DNSSEC Signing Behavior . . . . . . . . . . . . . . . . . . . . 5
   7.  UPDATE Behavior . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
     9.1.  NOTE RR Type Code . . . . . . . . . . . . . . . . . . . . . 6
     9.2.  NOTE OK Bit . . . . . . . . . . . . . . . . . . . . . . . . 6
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     11.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     11.2. Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

Hunt & Mahoney          Expires November 28, 2014               [Page 2]
Internet-Draft                   note-rr                        May 2014

1.  Introduction

   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 [RFC6891] 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.

1.1.  Reserved Words

   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.  The NOTE RR Type

   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 [RFC1035], e.g:

Hunt & Mahoney          Expires November 28, 2014               [Page 3]
Internet-Draft                   note-rr                        May 2014

       $ORIGIN example.com.
       joesbox   7200  IN  A       198.51.100.42
                 7200  IN  AAAA    2001:DB8:3F:B019::17
                 0     IN  NOTE    "Desktop system for Joe Smith, x7889"

3.  The NOTE OK Flag

   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.

     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     |DO|NO|                   Z                     |
     +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   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.)

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 NO bit is set.

   o  The NOTE RRset TTL MUST be zero.  Any configured TTL greater than
      zero is overridden.

Hunt & Mahoney          Expires November 28, 2014               [Page 4]
Internet-Draft                   note-rr                        May 2014

   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 NO bit is set in the query.)

   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 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.

5.  Recursive Server Behavior

   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:

   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

Hunt & Mahoney          Expires November 28, 2014               [Page 5]
Internet-Draft                   note-rr                        May 2014

      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.

   o  Nodes containing NOTE RRs but no other data SHOULD be omitted from
      NSEC [RFC3845] 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
   NOTE RR type.

9.2.  NOTE OK Bit

   EDNS(0) [RFC6891] 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

Hunt & Mahoney          Expires November 28, 2014               [Page 6]
Internet-Draft                   note-rr                        May 2014

   header would then be:

                +0 (MSB)                +1 (LSB)
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     0: |     EXTENDED-RCODE    |        VERSION        |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     2: |DO|NO|                   Z                     |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

10.  Acknowledgments

   Thanks to Paul Vixie, Stephen Morris, Chuck Aurora, and Jeremy Reed
   for suggestions and feedback.

11.  References

11.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
              RDATA Format", RFC 3845, August 2004.

   [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
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

Hunt & Mahoney          Expires November 28, 2014               [Page 7]
Internet-Draft                   note-rr                        May 2014

Authors' Addresses

   Evan Hunt
   ISC
   950 Charter St
   Redwood City, CA  94063
   USA

   Email: each@isc.org

   Dan Mahoney
   ISC
   950 Charter St
   Redwood City, CA  94063
   USA

   Email: dmahoney@isc.org

Hunt & Mahoney          Expires November 28, 2014               [Page 8]