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

神明達哉 <> Mon, 12 March 2018 17:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97FAE126579 for <>; Mon, 12 Mar 2018 10:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P2VriAr0vqF3 for <>; Mon, 12 Mar 2018 10:59:14 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27D851200C5 for <>; Mon, 12 Mar 2018 10:59:14 -0700 (PDT)
Received: by with SMTP id r66so9028847wrb.6 for <>; Mon, 12 Mar 2018 10:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wXvZ1W1nHdG5EOjvU8uoR4VLG8Ko3pAydfWvFoe03vI=; b=sshebE1bdGElLvwSjScoKC5pSVdBFjY7KDGYHyBcPWhZ55v6G6z7HrGCdx5bn6OrNd wUs5XZ9OaiLhfd9JM2dCfW/32Y+LgCGycNGjP3F2w8eBVJKM15YCesoK5vQBIGmzA8Ny 1g+y0ZaJjhgng11sIaV1b8fKENB71hOAQOMMm2XIASkhTXfPj5On5g9VaHaellxOSlHZ wjtmRBUO0MUxyM6IVhhlkLJsQJqj9CACUV+JsNczmyNi7IJ8GYtSbHDpXu9gbR4TmXku qkxL3mUkp/l3jnbAAck9kbrKQ+HWBPy7BwIsv5JbhnbojlgDbdIIZO+O4v/siyduhB42 GTHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wXvZ1W1nHdG5EOjvU8uoR4VLG8Ko3pAydfWvFoe03vI=; b=bnyL/I2QY6DnuSJpW0kueb6V6dH35iRIrn4kRT5ySXseGmp9edrSxfvsaEVMjYBgDk mfSH72NsgBwGsE7gxDmgWW1Brh1/Gk/4VeEAywGiX/5BIof7Rtp0FKyNUcFqTI1NbS58 H4x+28hbZSysN82nmY1f3VokwRlzew9cdp/2OC1u6tXRSAmmel9M3UBGeBr2BGindhH0 rWvyaGAYIUtqotea8OopNDAVoswSlzNicISDboDPjwcDzaYIpxh8DTKPzxLJfOJ9bEdq L6W3Om2X7+h0G9EYkuG6aEeDSEdyGlicTIGxYHv1FxBvQ22LwdQH6gAAPz/V1SNAW8Gu w1uQ==
X-Gm-Message-State: AElRT7E/Vpg3GDRFLZmuhRf18J6yeSCORNDCf4Kj9reGpMs98/A8tlZ3 vPxhD67W52E/bFY2R6y7ZCdwEeGeADX3fbCoTmQAZtr/
X-Google-Smtp-Source: AG47ELtHfuLbOmAqjSz/Qvme851zvtuCRTovO4fhxOLkfosPXVmtkxzUiOlj7fG1RsbQK3NjpOKnzNI5PJkBB5REg10=
X-Received: by with SMTP id z39mr2296348wrz.35.1520877552387; Mon, 12 Mar 2018 10:59:12 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 12 Mar 2018 10:59:11 -0700 (PDT)
In-Reply-To: <20180310162615.GA28458@jurassic>
References: <> <> <> <20180310162615.GA28458@jurassic>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Mon, 12 Mar 2018 10:59:11 -0700
X-Google-Sender-Auth: SZI1X0FP9VAfM7oudvLHZiFzrkE
Message-ID: <>
To: Mukund Sivaraman <>
Cc: dnsop <>, Ray Bellis <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-muks-dnsop-dns-catalog-zones-04.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Mar 2018 17:59:16 -0000

At Sat, 10 Mar 2018 21:56:15 +0530,
Mukund Sivaraman <> wrote:

> > 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
> Some background of how/why catalog zones feature in BIND 9.11 and the
> draft came to be is that we often got feedback about requiring better
> ways to provision zones and content on multiple nameservers, and
> different operators had different ideas about it. They wanted to improve
> performance, reduce the scope for mistakes, and have a method that
> worked across implementations.

I can understand that, and, if it mainly means different versions of
BIND, that's certainly possible.  If it also means a unified way that
works for multiple different vendors, I personally doubt it's
feasible; I suspect those operators assume some kind of magic happens
in the unified mechanism and gracefully handle differences in config
details amount different vendors' implementations, and would complain
when they realize it doesn't work that way.  So...

> The draft as it stands provides a way to specify config options within
> the zone, but does not specify an explicit list of options. There is no
> enthusiasm among the authors to do so in this draft.

...I'm personally not convinced this proposal will be useful as an
interoperable way to solve the issue (but, of course, it may be a good
idea as an enhancement to BIND) unless you actually address this

That said,

> > this proposal.  (in that sense, I'm curious: is there other DNS
> > developer than ISC that is interested in implementing this proposal?)
> So far: I was told that PowerDNS has implemented a plug-in/script that
> provides support for catalog zones.

if there is actually an interest (or better, implementation or
deployment cases) in having an interoperable way of synchronizing
primary/secondary meta info, it may become more convincing.  I'd
suggest you confirming the rumor and including the implementation
status in the draft.

JINMEI, Tatuya