Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt

神明達哉 <jinmei@wide.ad.jp> Thu, 08 March 2018 19:08 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC60B12711D for <dnsop@ietfa.amsl.com>; Thu, 8 Mar 2018 11:08:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 8hUsaJ6fFZ9P for <dnsop@ietfa.amsl.com>; Thu, 8 Mar 2018 11:08:39 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB87127076 for <dnsop@ietf.org>; Thu, 8 Mar 2018 11:08:39 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id h21so1298752wmd.1 for <dnsop@ietf.org>; Thu, 08 Mar 2018 11:08:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VpAXyHEmsRQ0yN7bQgja8lV7RX3CerMZwV9Kb/ixCeo=; b=NynHahs7Xm6+gYrwYwoCxchnNpMgSEL+6iRGs5QJHqCOi7jpn12+QWl5HvDFoPOjVK SWIbMQcTdb4u5bfCJIWxawdV7BsrxMmIJJ5yu8ZqlbOIlO20wBSmXB6iCE340VOWF2Ia JU6RXFWtWcmFF2vDh69PpstZDO6+/1HPGiKBfEDvd+an/UPsHqe45pueckCubVSApHPt s83eeDbeTb7/yI4QhqDQblOrbTpAVXEoQCnEbjFjs0sK/uFt/cheKLgrBzTaFn4WFKTN S4hO+ZrucIT0PFZKd8Vii8fuKNjGBwSYDGQz4Glt3Rt9lzqOOCVkGZ71G17baTetL5Aj 8i1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=VpAXyHEmsRQ0yN7bQgja8lV7RX3CerMZwV9Kb/ixCeo=; b=rLn36uM3jwaq6vrgDEBij7H3CBs+sST+pxHKmLOfZTzlpoyOfLphHLmPZQbwMpMP1C 1f0oYAvIcuaV6PRzg/8GPdfqJ4jctvBfLkIWM221wyFN+6Z1eO8+oW+VS2Xu+rbbsZWD 0+51sQPgfURhflK9KXwUZgpb/ENixH1cnyoXmLPbDwz4PAezRrtc5W7qOwHOIerrMUAV Kyd3og/QRucpv/NqZ49ZrzTvsqddO4z3Uc1HfmepseNC3EXhvSNYdIwp96btwBAQmFhV s3cgx0jlDHBhMlfjmZhaLtAfDFeQfWDof7hqKKwmOCRv90p+IRMYrvXeR0D+BMkF076t VicQ==
X-Gm-Message-State: AElRT7FEkFmBzCsKigexploJ45G3VBra9GoSJiEPds3LtmVY/7J6r4Sc yIzDaVzbPlg9AVynd1qC7y+ucFwvbjEE1uKWWdFt24N0
X-Google-Smtp-Source: AG47ELv3PFNt0XCdwrEPqc6mqP3aphbgQR6/XequFvTLjLL0uhYVKHLqWNX1p2QYzLhWxes+UfWjyKFw/hcJ4oYojNM=
X-Received: by 10.28.147.73 with SMTP id v70mr19812901wmd.128.1520536117749; Thu, 08 Mar 2018 11:08:37 -0800 (PST)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.223.134.1 with HTTP; Thu, 8 Mar 2018 11:08:37 -0800 (PST)
In-Reply-To: <9ab0208f-29e3-10b0-e360-125257b2b238@bellis.me.uk>
References: <151990782328.10030.7325038774873512859@ietfa.amsl.com> <9ab0208f-29e3-10b0-e360-125257b2b238@bellis.me.uk>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Thu, 8 Mar 2018 11:08:37 -0800
X-Google-Sender-Auth: NuE5RoqbGSj-o6NG-ous4qXsYHg
Message-ID: <CAJE_bqe-5-aD7yTkTSzu+fpSDEJw_TCYyL792cfqboDQXhmJ_g@mail.gmail.com>
To: Ray Bellis <ray@bellis.me.uk>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cFTw68GnoWGMGzmTw7gH7abFQJ0>
Subject: Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 08 Mar 2018 19:08:42 -0000

At Sat, 3 Mar 2018 22:07:57 +0000,
Ray Bellis <ray@bellis.me.uk> wrote:

> > Abstract: This document describes a method for automatic DNS zone
> > provisioning among DNS primary and secondary nameservers by storing
> > and transferring the catalog of zones to be provisioned as one or
> > more regular DNS zones.
>
> This version of the Catalog Zones draft has undergone significant
> restructuring, in particular to separate out the mechanism by which
> single-valued and multi-valued properties are specified.

I've read draft-muks-dnsop-dns-catalog-zones-04.  I see the motivation
of automating the synchronization of primary/secondary configurations.
Personally, however, I'm not (yet?) convinced that this should be
"standardized" in the form of an RFC or that this should be done
through another tricky use of DNS.  One big reason for standardization
is to have a unified way that is interoperable with multiple different
vendors.  But when it comes to configuration, difference on
vendor-specific options often matters, and unless the common basic set
of configuration is sufficiently common, a generic and interoperable
mechanism will be useless.  I'm not yet convinced about it regarding
this proposal.  (in that sense, I'm curious: is there other DNS
developer than ISC that is interested in implementing this proposal?)

I'm also not convinced that using standard DNS RRs is the best way to
implement the idea.  I see the advantage of it (most notably the
ability of synchronization via zone transfer), but various limitations
of the DNS protocol also make it unnecessarily complicated.  The issue
regarding DNAME is one example.  The way to implement the multi-valued
properties seems to be another.  I'm not convinced the advantages
obviously outweigh drawbacks.

Anyway, I have some comments on the draft body, below:

- Section 4.2.1

   NB: Catalog zones use some RR TYPEs (such as PTR) with alternate
   semantics to those originally defined for them.  Although this may be
   controversial, the situation is similar to other similar zone-based
   representations such as response-policy zones [RPZ].

  I think this justification is weak.  As this text seems to imply,
  I believe everyone agrees that (ab)using standard RRs for a
  different semantics in RPZ is controversial.  Perhaps in the case of
  RPZ a sufficiently large number of people accept it for reasons
  including inertia.  But I don't think a precedence of one
  controversial approach automatically justifies another controversial
  one simply because they are similar.  IMO the new one should have its
  own justification.

- Section 4.2.1

   It is an error for any single owner name within a catalog zone (other
   than the apex of the zone itself) to have more than one RR associated
   with it.

  It was not clear to me why this restriction was necessary, at least
  at the point of reading this text.  I guess this may be related to
  the ordering of ordered multi-valued properties, but I'm still not
  really sure about it.  It would be nice if it's clarified in more
  detail.

  Also, it's not clear what "error" means here.  Does that mean, for
  example, loading the zone should be refused if it violates this
  restriction?  I think this should be clarified.

- Section 4.3.4: minor typo, s/the the/the/

   specifying the property under the the sub-domain associated with the

- Section 5.1: s/the MUST/they MUST/ ?

   If the RDATA is split into multiple <character-string> elements the
   MUST be directly concatenated without any separating character.

--
JINMEI, Tatuya