[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

DNSOP Working Group                                          W. Krecicki
Internet-Draft                                                   E. Hunt
Updates: 6195 (if approved)                                   D. Mahoney
Intended status: Standards Track                                     ISC
Expires: January 7, 2020                                    July 6, 2019


 Domain Name System (DNS) Resource Record types for transferring covert
                information from primary to secondaries
                      draft-krecicki-dns-covert-00

Abstract

   The Domain Name System (DNS) Resource Record TYPEs IANA registry
   reserves the range 128-255 for Q-TYPEs and Meta-TYPEs [RFC6895] -
   Resource Records that can only be queried for or contain transient
   data associated with a particular DNS message.

   This document reserves a range of RR TYPE numbers for Covert-TYPEs -
   types that are an integral part of the zone but cannot be accessed
   via a normal QUERY operation.

   Uses for such records could include zone comments that are
   transferrable with the zone, expiry times for dynamically updated
   records, or Zone Signing Keys for inline signing.  This document,
   however, does not define any specific Covert RR types.

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 https://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 January 7, 2020.








Krecicki, et al.         Expires January 7, 2020                [Page 1]


Internet-Draft                 dns-covert                      July 2019


Copyright Notice

   Copyright (c) 2019 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
   (https://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
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Handling of Covert Resource Records . . . . . . . . . . . . .   3
     2.1.  The COVERT-OK option  . . . . . . . . . . . . . . . . . .   3
     2.2.  Protection of Zone Transfers  . . . . . . . . . . . . . .   3
     2.3.  Authoritative server behaviour  . . . . . . . . . . . . .   4
     2.4.  Recursive server behaviour  . . . . . . . . . . . . . . .   4
     2.5.  Interaction with DNSSEC . . . . . . . . . . . . . . . . .   4
     2.6.  Interaction with ZONEMD . . . . . . . . . . . . . . . . .   4
     2.7.  UPDATE behaviour  . . . . . . . . . . . . . . . . . . . .   4
   3.  Update to RRTYPE Allocation Template  . . . . . . . . . . . .   5
   4.  Security considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The Domain Name System (DNS) has no mechanism for sending control
   information in-band when transferring zone data from primary to
   secondary servers.  This document specifies a range of Resource
   Record TYPEs that can be used for this purpose.  Covert Resource
   Records can be transferred with the zone during zone transfer, but
   are not accessible by a normal QUERY operation.  It also specifies a
   method for informing the primary server that the secondary
   understands Covert semantics, and can be relied upon not to disclose
   contents of Covert RRs to querying clients.






Krecicki, et al.         Expires January 7, 2020                [Page 2]


Internet-Draft                 dns-covert                      July 2019


1.1.  Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "*NOT RECOMMENDED*", "MAY",
   and "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.  Handling of Covert Resource Records

   Covert Resource Records require special handling for both queries and
   zone transfers.  This document does not define any specific Covert
   Resource Record types.  When defined, those types may require
   additional handling on the server side as well; however, that is
   outside the scope of this document.

2.1.  The COVERT-OK option

   A client querying or a secondary transferring a zone from a primary
   server must explicitly signal its understanding of COVERT RR types.
   The mechanism for this is an EDNS option, with OPTION-CODE [TBD].
   OPTION-LENGTH MUST be zero and OPTION-DATA MUST be empty.

2.2.  Protection of Zone Transfers

   If a secondary server requesting a zone transfer does not understand
   the Covert semantics, then it will serve the Covert records to its
   clients.  Therefore a protection mechanism must be put in place so
   that secondary servers that do not understand Covert semantics do not
   receive Covert records.

   If a server requesting a zone transfer understands Covert semantics,
   it MUST send a COVERT-OK option in the transfer request.  If a
   primary server providing a zone transfer receives such a request, it
   then knows it can transfer the covert data and the secondary server
   will cooperate in protecting it.

   If the primary server receives a zone transfer request without the
   COVERT-OK option it MUST NOT transfer the zone with Covert RRs.  The
   default behaviour MUST be to refuse the transfer altogether, but an
   implementation MAY have a configuration option to allow transfer of
   the zone with Covert RRs stripped when transferring to a non-
   compliant secondary.








Krecicki, et al.         Expires January 7, 2020                [Page 3]


Internet-Draft                 dns-covert                      July 2019


2.3.  Authoritative server behaviour

   Covert Resource Records might contain sensitive data; therefore, they
   MUST NOT be served to regular clients.  An authoritative server
   queried for a Covert RR MUST return an answer as if the RRset the
   client client requested does not exist: NODATA if there are non-
   Covert Resource Records with the the same owner name or the node is
   an empty non-terminal, or NXDOMAIN otherwise.

   The server MAY provide a mechanism allowing clients to query for
   Resource Records in the Covert range, but it MUST be protected by a
   mechanism disallowing access from general public (e.g. an ACL or TSIG
   authentication) and access MUST NOT be enabled by default.  The
   server MUST verify that the query has the COVERT-OK option, and MUST
   NOT return COVERT records otherwise.

2.4.  Recursive server behaviour

   Recursive servers MUST NOT send the COVERT-OK option when iterating.
   If a COVERT record is received in response to an iterative query, it
   MUST NOT be cached, and it MUST NOT be returned to the client.  If a
   recursive server receives a request for a COVERT record, it MAY
   iterate to verify whether the answer should be an NXDOMAIN or NODATA,
   or it MAY simply return a NODATA response immediately.

2.5.  Interaction with DNSSEC

   Covert Resource Records are not available for regular querying and
   are used only internally.  Their presence in a zone should not, in
   any way, change the behaviour of that zone for ordinary clients.
   Therefore, when signing the zone, Covert Resource Records MUST be
   treated as if they do not exist: - Covert Records MUST NOT be signed.
   - Nodes that contain only Covert RRs and are not empty non-terminals
   MUST be ommited from NSEC [RFC4034] and NSEC3 [RFC5155] RR chains.  -
   Any Covert RR types MUST NOT be included in the Type Bit Map field of
   an NSEC or NSEC3 RR.

2.6.  Interaction with ZONEMD

   TBD

2.7.  UPDATE behaviour

   Covert Resource Records MAY be submitted via UPDATE [RFC2136].
   Servers SHOULD ignore prerequisites that specify Covert RR types, in
   order to conceal from untrusted clients the presence or absence of
   Covert RRs.




Krecicki, et al.         Expires January 7, 2020                [Page 4]


Internet-Draft                 dns-covert                      July 2019


3.  Update to RRTYPE Allocation Template

   The RRTYPE Allocation Template from [RFC6895] is updated to contain a
   checkbox for Covert-RR:


         B.2 Kind of RR:  [ ] Data RR  [ ] Meta-RR  [ ] Covert-RR


4.  Security considerations

   Since Zone Transfers are unencrypted, the contents of Covert RRs
   might still be snooped by an on-path attacker.  Protection against
   this kind of attack is outside the scope of this document, but it
   could be achieved by using, for example, a secure tunnel, a private
   network, or XFR over TLS transport.

5.  IANA Considerations

   IANA is requested to reserve range 61440-61695 (0xF000-0xF0FF) in the
   Resource Record TYPEs registry for Covert types.  The procedure for
   registering RR types from [RFC6895] should be used.

   IANA is requested to assign an EDNS option code to the COVERT-OK
   option.

6.  Acknowledgments

   TBD

7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <https://www.rfc-editor.org/info/rfc2136>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.





Krecicki, et al.         Expires January 7, 2020                [Page 5]


Internet-Draft                 dns-covert                      July 2019


   [RFC6895]  Eastlake 3rd, D., "Domain Name System (DNS) IANA
              Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
              April 2013, <https://www.rfc-editor.org/info/rfc6895>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Witold Krecicki
   ISC
   950 Charter St
   Redwood City, CA  94063
   US

   Email: wpk@isc.org


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

   Email: each@isc.org


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

   Email: dmahoney@isc.org
















Krecicki, et al.         Expires January 7, 2020                [Page 6]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/