Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

神明達哉 <> Tue, 28 March 2017 14:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84EFA129543 for <>; Tue, 28 Mar 2017 07:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 qlr-RL5sa_py for <>; Tue, 28 Mar 2017 07:44:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A3711287A5 for <>; Tue, 28 Mar 2017 07:44:47 -0700 (PDT)
Received: by with SMTP id i34so65958087qtc.0 for <>; Tue, 28 Mar 2017 07:44:47 -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=BSgX4q+e8dZfCNJnxbZgz+jpBSjVb6+Vla/ait3CqDs=; b=sqqBVLtG3F9m7GGx8qPoAXgNXBDuNirxS/9s0xrkjJBThhDrgNvv6uHLnwHRaGcj7K 5ozUGMpxcD1J4HgqRzl3sDLifN/a7jAhjb/ETBTQa+gd45IEY5/04R2JupgHCuk0hl0X anlLD8fiEn37TeU7fdCS7WcfX1g02OOB0oMF1P0DAM+k3jIhLq0KkR4WHuKKmcJbWCnu GDXFmjaNHfzK1uymRF6SEkNE2hyOGqB7nuQNyKzOi4hNlEn658cfyXxQvAHjXcmLvSlL 6G+dbzv3QmZxFI6V0k5qco2qsOuwKQGpnQEW//VsziDpvuZWh6so2DDPUFKrinzA7+Qe beRA==
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=BSgX4q+e8dZfCNJnxbZgz+jpBSjVb6+Vla/ait3CqDs=; b=RZSKiRxLUnW4cwkdDv0s1oTPxZzSuSvCY6R2fspzQqfCsx+BGPNgYWDccg5z7Y6dNU QlneV6GLI3pueHS9w/mWvaRhD1dqbsqN/KmlYsWWQgDvbmDp39XZo+NgDw6+go8Ky9s1 8T/kgEUxre8A198lXywinUkaqHRv8UQB4tAjM86A23xnSTtklvf7eogwMHZwTGXM+fi3 c0teGlRDhD3T9BlC/URHH9tkYLRxGCTncFJW7kueGhOah3L+cHiAkT1OSJxw0W2ORrX0 fYmb1WzVYjIC+JUiuxMb+g+QmoQheHiPwiAs0ZdSIw8tnJHT+tJCTr9UEQPId6jRMJ3M xq/A==
X-Gm-Message-State: AFeK/H08TJPwuIBrG3tXynavjmv7p1pD1/ZnVobOjU8U6TAd5+gweyE9YVCmmPZk7QylyfqP+1Sm1+Z7njttMg==
X-Received: by with SMTP id q45mr26976964qtb.220.1490712286267; Tue, 28 Mar 2017 07:44:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Mar 2017 07:44:45 -0700 (PDT)
In-Reply-To: <>
References: <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Tue, 28 Mar 2017 07:44:45 -0700
X-Google-Sender-Auth: 1N_YSpkoglFToeiuMMd-aw7twQo
Message-ID: <>
To: tjw ietf <>
Cc: dnsop <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Subject: Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any
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: Tue, 28 Mar 2017 14:44:49 -0000

On Thu, Mar 16, 2017 at 12:11 AM, tjw ietf <> wrote:

> During the first WGLC of draft-ietf-dnsop-refuse-any, several issues were
> raised by the working group that needed to be addressed. The Authors
> addressed the issues, but the changes are enough that there should be a
> second Working Group Last Call on the changes.
> Please take a few moments to refer the changes and let the working group
> know if the document is ready to move forward.   We're mostly looking for
> remaining issues that have not been addressed.

I've reviewed the 04 version.  I still do not think it's ready to move
forward as it still abuses HINFO.  I understand some other people
don't care about this point, and some others may even love the idea
(those who are using it right now).  But I've also seen yet some other
people have the same concern, so it shouldn't be only me.  I don't
think we have a clear consensus on this point yet.

To be hopefully a bit more productive, I have a specific counter
proposal: remove the mandatory text about the use of HINFO, e.g.,

- remove this bullet from section 4
   2.  A DNS responder can return a synthesised HINFO resource record.
       See Section 6 for discussion of the use of HINFO.
- remove ', in which case...' from Section 4.2
   If there is no CNAME present at the owner name matching the QNAME,
   the resource record returned in the response MAY instead be
   synthesised, in which case a single HINFO resource record SHOULD be

In fact, in terms of externally observable behavior, synthesizing
HINFO is just one form of "selecting one RRset of the QNAME"; the
HINFO is added and immediately removed at the time of answering the
ANY query, so in that sense we don't have to bother to mention it with
normative keywords.

Regarding the choice of HINFO in case of synthesizing, it may make
sense to specify a particular type as part of normative spec if many
other implementations are going to implement it.  But, as Section 8
explains two major general purpose open source implementations, NSD
and BIND 9, seem to only support the "subset" approach.  I suspect
it's actually not feasible for those generic implementations to
hardcode HINFO as long as their users could also use that type as
"real zone data".  Some special purpose implementation with full
control on what it configures, like in the case of Cloudflare, may
freely explore the approach of synthesizing HINFO at their discretion.
But I don't think it necessarily has to be a part of normative part of
this spec, at least at this moment.

I've also noticed a couple of other points I raised in my previous
review (
were not yet addressed.  These are (section numbers are for 03):

- Section 3

   1.  A DNS responder can choose to select one or subset of RRSets at
       the QNAME.

  'one or subset of RRSets' sounds a bit awkward to me

- Section 4

   A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, or MAY instead send a response with a single
   RRSet in the answer section.

  "a single RRSet" doesn't seem to be fully consistent of "one or
  subset of RRSets" stated in the preceding section (see the previous

JINMEI, Tatuya