IETF Logo Mail Archive

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

Geoff Huston <gih@apnic.net> Tue, 31 October 2017 15:34 UTC

Return-Path: <gih@apnic.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA5913F834 for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 08:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhG5ibkYIHkH for <dnsop@ietfa.amsl.com>; Tue, 31 Oct 2017 08:34:08 -0700 (PDT)
Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-eopbgr1290087.outbound.protection.outlook.com [40.107.129.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E118613F914 for <dnsop@ietf.org>; Tue, 31 Oct 2017 08:27:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ntL784ln7UpFOpxmd1hhVjbXHXEUFtF83BDxZ6WqSOY=; b=grru6awMHLM/ZbzjtbkZi1wnqMDH1FEgi7oZZEEAT1fZ0sjsQYNtO13l4B590JeYtxqVBKT3vJ0ymRJ0+xDa+P1VYhxmEsdUGvuOywHaBudxtvkyQ0srWRKCvKY4SCHhg2caPGxHW1HOlmGI8KaApmJ08+zMAhNjRnKqERVkUqE=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net;
Received: from [10.196.222.62] (199.91.197.98) by HK2PR04MB0691.apcprd04.prod.outlook.com (2a01:111:e400:5892::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Tue, 31 Oct 2017 15:27:29 +0000
From: Geoff Huston <gih@apnic.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 31 Oct 2017 19:27:06 +0400
References: <027a469c-5bb6-7940-fd89-55b91dd97275@bellis.me.uk> <20171030174052.GB87160@isc.org> <ce2c26be-d944-345c-0e63-d063682c78a6@bellis.me.uk> <alpine.DEB.2.11.1710311427140.22527@grey.csi.cam.ac.uk>
To: dnsop@ietf.org
In-Reply-To: <alpine.DEB.2.11.1710311427140.22527@grey.csi.cam.ac.uk>
Message-Id: <12DEDFB4-AA8B-4495-AFA0-CB72AE03B2FE@apnic.net>
X-Mailer: Apple Mail (2.3273)
X-Originating-IP: [199.91.197.98]
X-ClientProxiedBy: HE1PR0402CA0040.eurprd04.prod.outlook.com (2603:10a6:7:7c::29) To HK2PR04MB0691.apcprd04.prod.outlook.com (2a01:111:e400:5892::21)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: bd5e9f01-e94a-4cbb-9192-08d52073e6e7
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:HK2PR04MB0691;
X-Microsoft-Exchange-Diagnostics: 1; HK2PR04MB0691; 3:QQUeLkQykK9iCMSGzeeavU5CVT7X/muENnhF6tx4SdCenwaIgnQ4Ufy2HAMcb8nYIL8ZziIpw01nMImjk3S5KgghtIsVYNpDSSwP4pSnVtcHxx5tpjgmrj27vhwo9fbIO0Ty/DdhGyfH5OQu1hlmPg7zXlUDXLJYiVYHBnuMt9k5ifkwum8rts37970nX9LSW6mdoJs5gK6axcdLKdi9MB593Snxc/D56EZ/WmCFIhKYOoBUk2x1C+jnDzi8Lsex; 25:T+2T7Pa/RGbhrqgGKwAZeWXJ6pMvxIcAUYs8JUqEw8tEW8YzLHExOd4RGYlnxzNA+hPT0bfBXH6/osVTBV4kq3qrUP4PtIjW7srRJFBa+u4j2FyQzNDYzdCS5S1UGRPNmHs2HSawiib2H5UE8pkP1Vv3JLum5QzVlyB08h1fQOCMvkv1AlKEa8hU1QUENbSQbZq2STCs/FGsRBLnVTw7M688zvdhKeRCnge79Iivzuyd8g//gqQ4aCrsw1rboqjwmFxxw8YIpkRC5wpubyCYr9ijbVYFPWirQNY7AhGB8yrQ1f+cg5inuJYtH3kzXhC0qLPaZ9ujD2Xx111yF++JIQ==; 31:jrty+QLXOtwSbBTEbbT1vFqKqXdCcDeJcYrjJ9uyhMDgoxML7f6dPPXUi6pdqNSYAcsS8I8t0V8O3/3UTUgrsTBqhIypIQhMkHv8A0LoH1EoPwIRfOu/QA1ZRc4kYwKvb72aQpLDVZtMtEuZfOl4NCBXUN253CslfM7ZWKzyYpSQNcrAEZRz+1Mwm9hioU0+m+3O1eUR9H/EladllwHf5MPHOnR+Xy9R7d0I9Re3LE8=
X-MS-TrafficTypeDiagnostic: HK2PR04MB0691:
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: <HK2PR04MB06919F04E0BDCD7BC08B2067B85E0@HK2PR04MB0691.apcprd04.prod.outlook.com>
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231020)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HK2PR04MB0691; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HK2PR04MB0691;
X-Microsoft-Exchange-Diagnostics: 1; HK2PR04MB0691; 4:mb6RtAKryWEZUOZ9+IAE6Z+npkBZg67PkN5yA7cBoGtMWKxeA8HXE/fK7bfKLC82tdwd329HUaTocxlOBd0535IGwlH+ecqWCbbDW0OTqdjiPRL9ihV0KuIuMlSgwgD+2NgBW4XEgyZ5dikhMAqLfS1LyMIN4bcf074no8h9Ckn+0T4vQqQI/Hg0t7ng2h0m9PhhOb0A0OoLopDDroN+asnIxjs8O41CU3CQeYjp7hOSfO/4dG30VBekdevp+DtWHgkofO4+qy/idV35m48cTw==
X-Forefront-PRVS: 04772EA191
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(6009001)(39830400002)(376002)(346002)(24454002)(199003)(189002)(230783001)(93886005)(50466002)(50226002)(2351001)(106356001)(3846002)(6116002)(16576012)(6916009)(2950100002)(23676003)(47776003)(97736004)(83716003)(57306001)(316002)(6666003)(53546010)(189998001)(86362001)(33656002)(6486002)(82746002)(36756003)(25786009)(77096006)(5660300001)(16526018)(229853002)(66066001)(105586002)(81166006)(68736007)(8676002)(53936002)(8936002)(8746002)(81156014)(7736002)(305945005)(478600001)(6246003)(101416001)(2906002)(2361001)(76176999)(50986999)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:HK2PR04MB0691; H:[10.196.222.62]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1;HK2PR04MB0691;23:O+9FpLk/sMCpd+XLyhHy1NlEuEmwP7AYHauX/NOmLphjisowPI6/sVl+gF+liFhdZmfkfGzIa3oeh+bHOv6A+D41D+0K015FScqj7n4zRZfbBPQXW6U1ntCZgdQYiCwBFmXnWDK5SyPvbnx87l3vk8fWoG+O9jgNaJBEhcdxjHPmDl1Pv5V+FIPgYUjHf37tiClUvfMg19qfEELNO7ouGFOignxotL358tRrNKnuQDi0vdS5hug/E4AaHKYHTJeVOUTJYYRj7gvO0isrFZL7KntEbRlUvP7YLTeR5OLbGQutTl56Y3sG/OYVUYbOXBgvhp7EYbxFiLiVJyjOR+i4BRgJSJwgqjVAo9wXqIS0vtUwMwlzuaW8Qgp3a4ezXmAMpAvtdX2c07LOsF56WClCWnxyAdJi4CjKfbjS2wbMx7fZwqrWKgz0MlOqXTy8FHw4Dwa1+eD45QF/P+2/WSLo6Fhkz6/asMNxsdXLhtiexJt91y1olrPRbrsggcIaLZ0kG6T77swYAMXPgVSqhLcVgmeeNVcyRqZNOq9+9321/W+183/YEf1z/7hCojVAwedgdY7AaBLQdsgJjhl+qUFiW8f97A7B8/G8D6XT1pRrG9pMAJLgFVnNz9ob6bUeYfn1VuGcDlQmflqMyDSBWBEyN9psBJGVlr1VzJc/Urd00tqsyAlfzYWqq6IjogIrOUDcBZul/qW9ZcH7yHhcc/ACAundo480IFXXKYn5y0pdpGff/TCBRvUpw0BuiUN02JjEeazsNyXjYw+gozhnDlDckvY7di1B5e/frO2G2F1JwROR1WgQgBNvJ/p3TikuB1roEbLnWC//6yJW17sYDeePTJe6sooRHe0v/+dIU9Bcj4mfu7gld7r1ZUdC6Jy1d2N6ZYoDw78GiE2v/inI9FVt8NpQ4KxVf19OHdI2O5cmnCwASat3+FoIiCvA2QNQKJWrUndIEBrv+qMeGjNzDCxuObfZiT6sEol2lDqrbJsrhg2kDJCO0f1nEQKVG8LvC16xpE6OjzKQQYKkjedmfvPHnI9eTOrb0f/wJYHeKKqbqcNOePtYHCp5C0I3in0zuPK4dQanQeSk1NuA+t34s6InyV3uew/RAGT/Jw/KYqBFBRVCh74SUbr1SMzMio6ClVbQlxe+LrouVxOcLJglpiVM1Qnc3B0mU7sC0RQItWnN26SeuO6fO6xetaXjBRwIlogtFUh9W9RPcthNDthJPHV/NnR7CKp6ex79BMKb6jIHGtkyEh26pt+gnHSnFMuEyqxyEv4a4eW2VPKOfDYuE9jRTeKVn/ZqKMo2PbD0hOuvH0Y=
X-Microsoft-Exchange-Diagnostics: 1; HK2PR04MB0691; 6:mpzKqAZpigqn1Z2BfPM1/msH5mSh2ecPNrxKn5VHxMpAtjVjOYOZJSu6I9eTtpZOKnHschW529UEro47LTLfdM42GiN60hHJ3Iw9rmEc8aXMLWHXQAJo2PkGSy2Qh/SBLv8i6FZSPPgp9tROoGHeSqRIiMPOFhnTsHbOF61uDuZprZFY9BC6N7R3xHgzEfGJh8Nxxd3NoYa1BLQF47aQOznvMP3sSuAg2TDzznJzA21jKnd/pTnS0TExsBvEZ0A+zAAJlmwE5Z0VUeTL/ikJXkftq3s91D8aYJPlEXvI8cm5o/RB04Vnb0nWPnt5QT8BWejOdIqCjSNa7O3bhI7XXEiD73uGjFsmZq16l4UsKPw=; 5:TT83JShS8aV8xtBomxmLIkZvTtDZhoQpKkZcGx/Q3yF+gO8zTUBEnw1Yvi/hSAK0UB182WM5qRLrDEEv6qMcxmScpL+zUnemEv+HzJwY5QZERAm+SRwS6281lMl2Rn5uqD17Yu3CHY9eavdKGOR5b7vtJWsZXF7L7S4Ebx3nRzk=; 24:rMsOtL+Xickoih95wbJbr2JhR8KfJecDG1Mqdyq3x3XiuilmPqmS2UHQDsLtPcxfkWQEch/7G796JndFnpZjhZhg9+iISt2PENhF0OEq7AI=; 7:Yf2dylrzLOslqwRILTChgmCl8aj1chD09zwrO4OxpNxmQsptj0sX5yMvd/BShRwVy+OwoM5EhMow4ouR30RHgeyNteSsfJKurrA/QTwYimfqcvdUyCGbg00xg28b0wNReVmCGoKx8ezWVveZc+ors5ziw+QETVKy5wRyj0vVFNmZq/KVTJzjWm4VPceF0nNLfjr1blTqzx8pIP4FBBqpLp10+X3LZZEK5ETJPqUTH0m8fEf07il3yYRRwSINxWFn
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: apnic.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2017 15:27:29.8962 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: bd5e9f01-e94a-4cbb-9192-08d52073e6e7
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2PR04MB0691
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vsUQ-MqQDGQNjNqQugzOqlUJSk8>
Subject: Re: [DNSOP] draft-huston-kskroll-sentinel - naming format?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Oct 2017 15:34:15 -0000

> On 31 Oct 2017, at 6:34 pm, Tony Finch <dot@dotat.at> wrote:
> 
> Ray Bellis <ray@bellis.me.uk> 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. It's the signal back to the querier that’s important here. So even caching is quite ok. 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. 

Geoff

v2.23.0 | Report a Bug | By Email