[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Internet Engineering Task Force                                P. Spacek
Internet-Draft                                             Red Hat, Inc.
Intended status: Standards Track                         August 27, 2015
Expires: February 28, 2016


  Clarifications to the Dynamic Updates in the Domain Name System (DNS
                         UPDATE) specification
                  draft-spacek-dnsop-update-clarif-01

Abstract

   This document clarifies interaction among Dynamic Updates in the
   Domain Name System (DNS UPDATE), Classless IN-ADDR.ARPA delegation,
   and Secure Domain Name System (DNS) Dynamic Update in the presence of
   CNAME/DNAME redirections.

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 February 28, 2016.

Copyright Notice

   Copyright (c) 2015 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
   described in the Simplified BSD License.



Spacek                  Expires February 28, 2016               [Page 1]


Internet-Draft          DNS UPDATE clarifications            August 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Document Conventions  . . . . . . . . . . . . . . . . . . . .   2
   3.  Problem Description . . . . . . . . . . . . . . . . . . . . .   3
   4.  Clarification to Requestor Behaviour  . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   This document clarifies interaction among Dynamic Updates in the
   Domain Name System (DNS UPDATE) [RFC2136], Classless IN-ADDR.ARPA
   delegation [RFC2317], and Secure Domain Name System (DNS) Dynamic
   Update [RFC3007].

   It was identified that common implementations using DNS update
   protocol often ignore existence of CNAME/DNAME redirections and, as a
   result, fail to update records if redirection is used.  One common
   example is failure to update PTR records in classless IN-ADDR.ARPA
   zones.

   [RFC2317] describes how to use the CNAME records in IN-ADDR.ARPA DNS
   zones to split administrative control over IN-ADDR.ARPA data for
   classless networks.  The described method is perfectly compatible
   with standard DNS resolution but DNS update requests need special
   handling described in this document.

   This clarification is applicable to parties wanting to update records
   in IN-ADDR.ARPA and other zones without changing existing CNAME/DNAME
   redirections.  A typical example are PTR record updates in zones
   which might potentially use [RFC2317].  This clarification is not
   applicable to cases where the purpose of the DNS update is to change
   CNAME/DNAME redirection.

2.  Document Conventions

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

   Terms "requestor", "update message", and names of update message's
   sections are used in the same sense as in [RFC2136].

   Examples involving IN-ADDR.ARPA zone and PTR records are referring to
   [RFC2317].



Spacek                  Expires February 28, 2016               [Page 2]


Internet-Draft          DNS UPDATE clarifications            August 2015


3.  Problem Description

   The problem described herein typically occurs when an implementation
   intends to update resource records resolvable by using particular
   owner name while keeping all CNAME/DNAME redirections intact.  In
   other words, the purpose of the update is to change resource records
   associated with terminal node of (potential) chain of redirections
   starting at a known owner name.

   Typically, this is the case when the resource records are associated
   with a known owner name or an owner name that is derived from data
   obtained outside of DNS.  For example, implementations often
   translate IPv4 address to DNS owner name using the algorithm from
   [RFC1034] section 5.2.1.4:

   192.0.2.1 -> 1.2.0.192.in-addr.arpa.


   The problem is that implementations often use this original node name
   in an Update Message without checking for redirections.  If the
   original owner name contains redirection, then this behavior results
   in an attempt to add or delete another record to or from a node that
   already contains the CNAME record, and the update fails.

   Such inappropriately constructed update request will be silently
   ignored in accordance with [RFC2136] section 3.4.2.2.  Alternatively,
   an error will be reported to the requestor if the non-existence of
   the CNAME record was added as a prerequisite to the Update Message.

4.  Clarification to Requestor Behaviour

   Please see applicability note in Introduction (Section 1, Paragraph
   4).

   A Requestor MUST resolve (canonicalize) the original owner name (e.g.
   the one derived from an IPv4 address) to a canonical owner name
   before constructing the Update Message.  The requestor MUST follow
   whole chain of redirections until the terminal node of the chain is
   reached and use canonical name found at the terminal node.
   Implementations MUST detect infinite loops.

   Canonical owner name MUST be used instead of the original owner name
   in the resulting Update Message:

   o  All names used in the Prerequisite and Update sections MUST be
      canonicalized as specified above.  Only prerequisites concerning
      the CNAME or DNAME records are an exception to this rule and
      should not be canonicalized.



Spacek                  Expires February 28, 2016               [Page 3]


Internet-Draft          DNS UPDATE clarifications            August 2015


   o  ZNAME in the Zone Section has to contain the name of the zone that
      encloses the canonical owner names.

   o  An implementation MAY chose to use canonicalized names in RDATA
      and an Additional Section.  This is an application specific
      decision.

5.  IANA Considerations

   This draft does not involve IANA Considerations.

6.  Security Considerations

   Canonicalization process changes the owner name which is going to be
   affected by the update.  An active attacker might interfere with the
   canonicalization process and trick the requestor to update a node of
   the attacker's choice if the canonicalization process is not secured
   by using DNSSEC or by other means.

   Security properties of DNS updates using only DNS UPDATE [RFC2136]
   without any security mechanisms on top of it are vulnerable anyway
   because an active attacker can very well modify the update message
   itself.

   Canonicalization generally increases overall risk for implementations
   of Secure DNS Dynamic Update [RFC3007] because an attacker might have
   a chance to modify the owner name in an Update Message before the
   message is signed by the requestor.  An implementation might decide
   to accept canonicalized names only on condition that the overall
   security status of the canonicalization process is sufficient
   according to the local policy.  Because the chain of redirections
   might involve multiple DNS zones, implementations MUST use the lowest
   security status from all links in the chain of redirections when
   doing security decisions.

   For example, a strict implementation might accept canonicalized names
   only on condition that all redirections were secured by DNSSEC and
   the security state of all redirections was "secure".  Another
   implementation might decide that security checks on a server side are
   sufficient, so requestors will accept canonical names obtained using
   insecure protocols.  In case of PTR records, a server might require
   the TCP transport and map an IP address of the requestor to the
   canonical owner name and/or check data in an Update Message with the
   requestor's identity.

7.  Normative References





Spacek                  Expires February 28, 2016               [Page 4]


Internet-Draft          DNS UPDATE clarifications            August 2015


   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC2317]  Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
              ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, November 2000.

Author's Address

   Petr Spacek
   Red Hat, Inc.

   Email: pspacek@redhat.com





























Spacek                  Expires February 28, 2016               [Page 5]