Re: [DNSOP] Updated KSK Sentinel document

神明達哉 <> Wed, 14 February 2018 22:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4320012426E for <>; Wed, 14 Feb 2018 14:05:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 drGDLQmQ3qV5 for <>; Wed, 14 Feb 2018 14:05:11 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8E691201FA for <>; Wed, 14 Feb 2018 14:05:11 -0800 (PST)
Received: by with SMTP id v65so1444432wrc.11 for <>; Wed, 14 Feb 2018 14:05:11 -0800 (PST)
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=JIQXNJS+ggcxoyRdTtLpAsiEm318NYM4NHacdA4oWI4=; b=lkjLaT2dsDUpp4QqUnYUhzOoBjHF1iwkNKSQpuz8VNa4ctz21eKYe88o+sOxXCmZ6V xZcFgqkCwp5z6vOtq7BqoVtNLgHjUK48eJdgVAGiCUDnZ2NMBxPRsDSoEAzZyAR5ycmS msf1uNhpXio8OCT6kTTMjynjLdZJ/nzs/ryjlyqN7Rm8IrcbeWzDdu+YMx6xUkuvRvhI fEVJ+U0nK0qg7lS5w0qc7PgCTsVOaQO7zXGd+In6L/nYVlJ5srcnkDWEvxfgFeSbxLxZ rmunNaFLimcGYxpnqt2NE9lqNHpsKXQZ1kDMoQj+oVpkQ7uVAg/wrZE5mXKffq6EBF2l B9Iw==
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=JIQXNJS+ggcxoyRdTtLpAsiEm318NYM4NHacdA4oWI4=; b=eDUWmfUCWT+kBSF6DRPh9tC5ENt4obRdqLco0Rnu5LL9BoD/WJXpeDpTMdkb9D1smf MByUF8heuNCMK9wLroKS9ED8+lhEEPPcDIhnE6PomdHlkWntbmf2Ni+6yYob6YL6BhC1 554k+iig29cmePa5/T2yza41RUv2jnKPh5fzQ8cW7okd5BvXPgAZyxUSuS4QpHovfG1+ IED6iSXy4XtnRz4p528uaRF+oTi81Fc67AlLKWeN3l25uaMAN0Gvw6G3JJeIYAAuPDsC 5azFVtbWSponYc7mPQgrn7+nWVm+P+eAM+3Hv3x265Na6CL0hEd1WkKdMS5rwxLnNREn 4Gpg==
X-Gm-Message-State: APf1xPAhIgfQyMFAsv5DZEiKkqz8bsiBWp/IXnrYfM6lodpViqIIZbZO NzbRwaG/K/UtWFaabZkEPlkZxOWH4xhnAUjXPkBC+IvN
X-Google-Smtp-Source: AH8x225ifeAxLE9ITVTL8tbOBs0/91JaRmiCWv78EDh6bYPJx2dB+Bfi+rCPIXi+jR3H1YI5PxnT4/NgTASrO5NNLPg=
X-Received: by with SMTP id l102mr633685wrc.84.1518645909793; Wed, 14 Feb 2018 14:05:09 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 14 Feb 2018 14:05:09 -0800 (PST)
In-Reply-To: <>
References: <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Wed, 14 Feb 2018 14:05:09 -0800
X-Google-Sender-Auth: xVpquUiMRMShnkMx4EaoOeGOGCw
Message-ID: <>
To: Warren Kumari <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] Updated KSK Sentinel document
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: Wed, 14 Feb 2018 22:05:13 -0000

At Mon, 12 Feb 2018 15:28:50 -0500,
Warren Kumari <> wrote:

> Anyway, we've finally posted an updated version -

I've read draft-ietf-dnsop-kskroll-sentinel-01 (this is my first
careful read of this draft) and found it generally well-written.

I have some comments on 01.  These are basically editorial.

- General
  I think it's worth pointing out that SERVFAIL can be returned for
  various other reasons and the detection mechanism relying on it
  isn't reliable.  This is probably okay given the purpose of this
  detection, but I think it's better to note it explicitly.

- Section 1.1
   Address Record: Throughout this document we use the term Address
   Record (AR) to mean an A or AAAA record.  [...]

  I actually didn't find this term other than here and Section 9
  (change log).

- Section 1.1 and throughout the draft

   AAAA records and the IPv6 documentation prefix (2001:DB8::/32) as

  I'd suggest using lower-case letters to show IPv6 addresses and
  prefixes, following the recommendation of RFC5952.  It's not a big
  deal but it would be better if we can be more consistent on the
  choice of letter case in RFCs.

- Section 2

   Charlie's resolvers are validating, but they have not been upgraded
   resolve it).  He is able to fetch both of the other resources - from
   this he knows (see the logic below) that he is using legacy, non-
   validating resolvers.  [...]

  Do you mean "he is using legacy validating resolvers"?  If it's not
  a typo, the behind logic isn't obvious to me and it would help if
  you explain it in more detail (instead of just referring to

- Section 3

   [...] Note that
   the test is "Is there a key with this KeyID in the resolver's current
   trust store for the DNS root", not "Is there any key with this KeyID
   in the trust store", nor "Was a key with this KeyID used to validate
   this query?".

  Unless I miss something, the draft doesn't clarify its use is
  limited to root KSK until the next paragraph of this, so I suspect
  this statement will confuse a fresh reader who reads this doc from
  top to bottom without a particular knowledge of background
  discussion.  I'd suggest noting it somewhere before this part,
  perhaps in the introduction (and maybe also in abstract).

- Section 3

   [...]  Note
   that the <tag-index> is specified in the DNS label using hexadecimal

  I suggest clarifying whether '<tag-index>' contains leading 0s
  somewhere in the document (this may not be the best place to do so,
  but this is the first reference to 'tag-index' that made the
  question occur to me).

- Section 3

   If the resolver has not placed a
   Root Zone Key Signing Key with tag index value matching the value
   specified in the query into the local resolver's store of trusted
   keys, then the resolver should return a response indicating that the
   response contains authenticated data according to section 5.8 of

  Should we perhaps define "store of trusted keys" more precisely?
  For example, if a key is in the "AddPend" status (per RFC5011) for
  the resolver, should it be considered in the "store of trusted

- Section 3

   This mechanism is to be applied only by resolvers that are performing
   DNSSEC validation, and applies only to RRset responses to an A or
   AAAA query (Query Type value 1 or 28) where the resolver has
   authenticated the response RRset according to the DNSSEC validation
   process and where the query name contains either of the labels
   described in this section as its left-most label.

  Is the RRset in 'response RRset' intentionally added (or in other
  words can't it just be 'response')?  Perhaps is the intent to
  exclude negative responses?  In any case I think the intent should
  be clearer here.  And if a mere 'response' suffices it's probably
  less confusing to just say so.

  BTW, you might want to say 'a query for an Address Record' or 'an
  Address Record query' instead of 'an A or AAAA query' (I guess
  that's the intent of the introduction of this term.  See also my
  first comment on Section 1.1 above).

- Section 4

   o  Vleg: A DNSSEC-Validating resolver that does not implement this
      mechanism will respond with an A or AAAA RRSET response for
      "kskroll-sentinel-is-ta", an A record response for "kskroll-
      sentinel-not-ta" and SERVFAIL for the invalid name.

  + s/RRSET/RRset/?
  + 'an A record response' should be 'an A or AAAA record response' or
    it's revised using the "Address Record" term.  Same comment
    applies to other part of this section including the table.

JINMEI, Tatuya