Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-edns-key-tag

神明達哉 <> Fri, 07 October 2016 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61ACE1296DC for <>; Fri, 7 Oct 2016 11:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0kEbZwn8nhJ8 for <>; Fri, 7 Oct 2016 11:53:42 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 528611296DA for <>; Fri, 7 Oct 2016 11:53:42 -0700 (PDT)
Received: by with SMTP id z190so38496896qkc.2 for <>; Fri, 07 Oct 2016 11:53:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mQbK6qvGQ4FtMXoO/BEEPAHhmole5UtbS/DU500jJo4=; b=QfqwC5mQ8U2p4tlybAbk0wSsc98cpW/ikwAt3QdHtutb/aGKPUewmNx6PnB6tjr5YS FVdbwjnNQM9igMQraRU4PSPU5pUv3A5xdklKAW/r7mkgt5AcDgEMnM33OBuxJRqoEicW RjSqLczoHauET75Y8ieqE5SyPTxJpjuDwJOL2ASDBTw1atvim0vkLsiP7RsmAGiRk1k1 I+2m+f0FlXUGAPHwVmuAhT502vEPjImsfXzR/DEeoJbpYcaM+NRdCL2cnSVTmN36jBET tFpsLKfFRBnao6uCa9DbXT+IXV+KVq6789GNU9AIqvxyyYYr1L7uMq+bGZZ88OpgfufM A1bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mQbK6qvGQ4FtMXoO/BEEPAHhmole5UtbS/DU500jJo4=; b=dIh5z/eILp/GFeP93fO+bSWXw2dW2vK1J59gtHCTX9Lxrp1UUCMu3du45UjzHexICt MwgTaOS+wpdSCh3CSCDgR2rX60am3CN6aXRIC9R+oLlSg7Vabc1I4sbMdPXBUgePi+Kd GsOW1UZsxw/Im2iajz0rgvW/eZLnyEsCqp6wwO5gCzE+xOH+p0e5aXZ/4b+JNKrRCeXb qHxY/vvniW+wt482hHmjdpLyD1ayUnSFTwaW1BBL6qHarLDX1B/U81m67Ho9QpE0UgLh qB69AY79/+lwANPzURjXjPnJMHWbtixBUHkrepVmQSMFUtXb9IZQe0n7i5UhxN9H+UDI nPpw==
X-Gm-Message-State: AA6/9RnqPkECm41b+8i/lJPdudPU8eWFdmAlUjykYCquXNVnHFwlkXqXc0bz012ARyVuFPaJaASKWeDGFdYexQ==
X-Received: by with SMTP id x194mr20530744qkx.94.1475866421444; Fri, 07 Oct 2016 11:53:41 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 7 Oct 2016 11:53:40 -0700 (PDT)
In-Reply-To: <>
References: <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 7 Oct 2016 11:53:40 -0700
X-Google-Sender-Auth: F_rxdxklro6OIsHirIm_PPfdZGI
Message-ID: <>
To: Tim Wicinski <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: dnsop <>
Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-edns-key-tag
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Oct 2016 18:53:44 -0000

At Thu, 6 Oct 2016 03:00:36 -0400,
Tim Wicinski <> wrote:

> The authors for this document have addressed some lingering  outstanding
> issues, and it appears ready for Working Group Last Call.
> This starts a Working Group Last Call for:
>     draft-ietf-dnsop-edns-key-tag
> Current versions of the draft is available here:
> Please review the draft and offer relevant comments. Also, if someone
> feels the document is *not* ready for publication, please speak out with
> your reasons.

I've read the 03 version of the draft.  I think it's basically ready
for publication.  However, I have two new points to discuss, which may
result in some non-trivial updates (although they may not be
substantial to warrant another WGLC).

1. regarding recursive resolvers (, I wonder whether we
   want to explicitly note that the recursive servers MUST NOT (I
   think) forward a DNSKEY query with an EDNS key tag option when it
   already has it in the cache simply because the set of key tags in
   the originally query is different from its own set of key tags.

2. regarding the following note in Section 5.3:

   [ Note RFC1035 says NULL
   RRs are not allowed in master files, but I believe that to be
   incorrect ]

  perhaps we should officially update RFC1035 and clarify that NULL is
  now allowed in master files?  Even if the usage in the authoritative
  side (such as the example shown in Section 5.3.1) is not a normative
  part of this draft, the use of NULL RR is, and so it would be better
  to assure such configuration won't be considered a non-compliant

JINMEI, Tatuya