Re: [DNSOP] draft-fanf-dnsop-rfc2317bis-00 vs. draft-spacek-dnsop-update-clarif-01

Petr Spacek <pspacek@redhat.com> Thu, 05 November 2015 03:19 UTC

Return-Path: <pspacek@redhat.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CA51A1A59 for <dnsop@ietfa.amsl.com>; Wed, 4 Nov 2015 19:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5slLW8y1ZOy for <dnsop@ietfa.amsl.com>; Wed, 4 Nov 2015 19:19:13 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFA41A1A58 for <dnsop@ietf.org>; Wed, 4 Nov 2015 19:19:13 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 0A3FEC0D61C0 for <dnsop@ietf.org>; Thu, 5 Nov 2015 03:19:13 +0000 (UTC)
Received: from pspacek.brq.redhat.com (ovpn-204-18.brq.redhat.com [10.40.204.18]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tA53JAVR000984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <dnsop@ietf.org>; Wed, 4 Nov 2015 22:19:12 -0500
To: dnsop@ietf.org
References: <563A69D0.7090208@gmail.com> <alpine.LSU.2.00.1511042144130.28816@hermes-2.csi.cam.ac.uk>
From: Petr Spacek <pspacek@redhat.com>
X-Enigmail-Draft-Status: N1110
Organization: Red Hat
Message-ID: <563ACAAC.4080209@redhat.com>
Date: Thu, 5 Nov 2015 04:19:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <alpine.LSU.2.00.1511042144130.28816@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/CVFejzh5YXX_CEMzm0gybx2seL4>
Subject: Re: [DNSOP] draft-fanf-dnsop-rfc2317bis-00 vs. draft-spacek-dnsop-update-clarif-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2015 03:19:16 -0000

On 4.11.2015 22:53, Tony Finch wrote:
> Tim Wicinski <tjw.ietf@gmail.com> wrote:
>>
>>     draft-spacek-dnsop-update-clarif, Spacek

Grrr, dnsop session ended right on time and Paul Wouters did not get necessary
30 seconds to present this draft to the WG.

Anyway:

> Note that my 2317bis draft has a slightly different take on UPDATE vs
> classless reverse DNS. The UPDATE section of my draft is entirely due to
> Petr's draft, so I'm very grateful to him for pointing out the problem.
> I'm interested in opinions about
> 
> - should this be a separate draft or is it sensible to put it in rfc2317bis?

It could be combined with rfc2317bis because there is very tight relation
between these two. However spacek-update-clarif is more generic and IMHO we
should extend rfc2317bis to incorporate the generic-ness before dropping
spacek-update-clarif.

> - is the indirection problem specific to classless reverse DNS (which is
>   the approach I took) or does it apply everywhere (which is what
>   Petr Spacek's draft says)?

Personally I do not see why it should be specific to ARPA sub-tree ...
Conceptually it is the question if client wants to update RR at the terminal
node or on the node client can name beforehand ("reverse DNS query name" is
one example of a name known beforehand).

Thinking about it a bit more ... I can see that RFC2317bis should make
canonicalization mandatory for reverse sub-trees and all other cases should be
left to the implementation to decide. Let's see if we can do it in one document.

> - is my detailed suggested UPDATE behaviour sensible?
> https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis-00#section-9

Most importantly, I believe that limiting the new behavior ("canonicalize
first") to PTR RR type is a bad idea. We have DHCID, EUI48, EUI64 and people
are certainly using other RR types in the reverse sub-trees too (TXT comes to
mind...).

Even if we decide in the end to mandate the new behavior to ARPA sub-tree we
surely should not limit ourselves to PTR.

I would remove limitation to PTR and add a paragraph about sub-trees other
than IN-ADDR.ARPA and IP6.ARPA. For a while I was considering adding a
limitation to "*not* CNAME/DNAME", but IMHO your sentence "these requirements
do not apply if you are using DNS UPDATE to deploy classless IN-ADDR.ARPA or
IP6.ARPA delegations" is better.

I'm proposing to use following text (few nitpicks included):

"""
9.  Dynamic DNS UPDATE for reverse DNS sub-tree

   This section updates the DNS UPDATE specification [RFC2136].  It
   specifies additional requirements for DNS UPDATE clients, so they can
   dynamically change DNS records in reverse sub-tree in a way that is
   compatible with the techniques described in the previous sections.
   It applies both to the IPv4 reverse DNS under IN-ADDR.ARPA and
   the IPv6 reverse DNS under IP6.ARPA.

   These additional requirements only apply to DNS UPDATE clients that
   wish to add, remove, or change records in the reverse DNS sub-tree.
   Exception is that these requirements do not apply if you are using DNS
   UPDATE to deploy classless IN-ADDR.ARPA or IP6.ARPA delegations.
   No new requirements affect other uses of DNS UPDATE, i.e. uses outside
   of IN-ADDR.ARPA or IP6.ARPA sub-trees.

   In this section, we use the term "reverse DNS query name" to mean a
   name under IN-ADDR.ARPA or IP6.ARPA which a resolver uses when making
   a reverse DNS query.  The resolver expects this name to resolve to a
   PTR or related RRsets, but (as described in previous sections)
   it does not have to be the direct owner of the RRsets but can instead
   be an alias.

   The problem addressed by this section is that DNS UPDATE clients
   sometimes use a reverse DNS query name in an UPDATE message without
   checking for CNAME or DNAME redirections.  If the usual reverse DNS
   query name is an alias, then this behavior results in an attempt to
   add or delete a record to or from a node that already contains
   the CNAME record, and the update fails.

   Aside:  Presumably the UPDATE will also fail if the node is occluded
      below a DNAME record, but neither [RFC2136] nor [RFC6672]
      specifies how a server out to react to attempts to UPDATE an
      occluded domain name.

   Please note that this problem is generic. For names outside of
   IN-ADDR.ARPA or IP6.ARPA sub-trees it is up to implementation
   to decide if it is necessary to update aliases itself or if it is
   necessary to update RRsets at terminal node of alias chain and thus
   method described in the section 9.2 needs to be applied.


9.1.  Requirements for updating records in the reverse DNS

   When updating a record in the reverse DNS sub-tree, an UPDATE client
   SHOULD NOT simply convert the IP address to a reverse DNS query name
   and send an UPDATE request for RRsets at that name.  It MUST
   NOT assume the zone cut falls on a particular boundary such as /24
   for IPv4 or /64 for IPv6.
"""


Additionally, Security Considerations section does not mention risks mentioned in
https://tools.ietf.org/html/draft-spacek-dnsop-update-clarif-01#section-6

It would be nice to copy&paste/incorporate the text from there. These risks
should be explicitly mentioned.

Now it is ~ 4 AM here so I wish the text above makes sense :-) I will read the
procedure in section 9.2 carefully again this week, but it seems okay at a
first glance. (For generalization proposed above we would have to drop "PTR"
from the very last bullet in 9.2. Suggested behaviour but that is it.)

I believe that we can drop draft-spacek-dnsop-update-clarif in favor of
rfc2317bis if concerns above can be resolved.

Have a nice day!

-- 
Petr Spacek