Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?

Geoff Huston <> Tue, 31 October 2017 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E756913F831 for <>; Tue, 31 Oct 2017 08:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 V6KkweCyw-lR for <>; Tue, 31 Oct 2017 08:30:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6597513F8B7 for <>; Tue, 31 Oct 2017 08:23:16 -0700 (PDT)
Received: by with SMTP id b9so24037357wmh.0 for <>; Tue, 31 Oct 2017 08:23:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=61mNDokGB9NoVCMqagymHQDB0nYnvd6WPAhsyg7lvN4=; b=ravfmMBmKLYn83HPdTufkthHbbfK9hNMN/ghFl1C6yelJCXqHV5hiYZXtAOakEmNke HB9RktJ28+6/BhDCIfsETAtCtC/jmDpEiRtNzBCdYd9+8CSsFEkmNetGebp+flVV1qJR tvvTR89CrvagDqQST4cykbX4S2vPyLq1o9U1IPM+qL8Ry5KG7nHEPvpzFc7IQ6TJgTws 4DbnkRYmdg3oLjysO0THAc2gVgF0M+zN+hWPIgbgf58dyWnkGOjhYaWt8UVBX4x5PWsK Q9A5ZRzwBMX8S7pevP76rdkNeM4DhlWZ6UOAX0rO2/UDWjEBSkztr3uFSurf0FIiyzGt F4KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=61mNDokGB9NoVCMqagymHQDB0nYnvd6WPAhsyg7lvN4=; b=tBt4POJjPmlgG0SDCqhY28M17I+jAOLYXKzUTfOQqb1BHU5tL5kpFWCJ3CgyTG4MFB a4k3KR4SDfLXtpIVyN97RcfJMbD1NOg4TKAfurDnQhN9YizTpw8M+OpPx8hPMvcKJtL1 bTy9E4Y3pUlp/1juqc14t4p4gL/5BPAfyFKGVtF+0scpubDm2ukZhPoM7jQR9FBXM1SD 3CYVNU2xZ3T0YWMiT14JI2Oylu729vfVAlwG4FxppDmspSOxmJxfClXLn3k99Vfi6Y1K b8MVXqPZLQTWv5G2WvQGWtbfYzOEFP1Bkx46VLk1wYnSYVd7UMV7ovwvvnbunLCCdjM4 XwYw==
X-Gm-Message-State: AMCzsaWe/Ai4ajzDyUmQzAEPPRsCKkwB3VvT/xymUSpZ1YfCDdV3BvHG 1wHnFBxPDQqTDUlvF10Wjcs=
X-Google-Smtp-Source: ABhQp+TywvcMDAqOyYK4SJvrAqwKXqXjK2xCtLY32lO9NdGLoQKBlmrb5YT5ifhcel6s12M87eKFbQ==
X-Received: by with SMTP id f64mr2082268wme.42.1509463394773; Tue, 31 Oct 2017 08:23:14 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id v35sm4371951wrc.13.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Oct 2017 08:23:13 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Geoff Huston <>
In-Reply-To: <>
Date: Tue, 31 Oct 2017 19:23:10 +0400
Cc: Ray Bellis <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Tony Finch <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?
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, 31 Oct 2017 15:30:03 -0000

> On 31 Oct 2017, at 6:34 pm, Tony Finch <>; wrote:
> Ray Bellis <>; wrote:
>> On 30/10/2017 17:40, Evan Hunt wrote:
>>> IIRC we discussed it, and were concerned that _ta. could be cached as
>>> nonexistent by servers implementing QNAME minimization.
>> How would that happen, at least so long as _ta responds like any other
>> empty non-terminal?
> It's NXDOMAIN. (It'll also fall foul of RFCs 8020 and 8198.)
> The problem occurs if you have a validator behind a cache. The cache will
> prevent downstream id._ta. queries from reaching the root, so any
> downstream trust anchor variation will be lost.

The mechanism does not rely on these queries reaching the root. The key aspect is the signal back to the querier. So even caching is quite ok here. The critical aspect of this mechanism is that it is not intended to measure resolvers, but detect if an end user has a DNS resolution environment that will (or will not) be impacted by a roll in the KSK to a named (via a key tag value) new KSK.

Certainly it would remove some of the QNAME minimisation issues if the test is based on a single label as defined in the draft, and on reflection I _think_ its probably more robust if its the terminal label, but frankly I’m not sure about that latter point.