[DNSOP] zonemd/xhash versus nothing new
Paul Wouters <paul@nohats.ca> Fri, 27 July 2018 22:17 UTC
Return-Path: <paul@nohats.ca>
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 AD9B5130E0A for <dnsop@ietfa.amsl.com>; Fri, 27 Jul 2018 15:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 2HVYUABpMx-l for <dnsop@ietfa.amsl.com>; Fri, 27 Jul 2018 15:17:46 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A243812E039 for <dnsop@ietf.org>; Fri, 27 Jul 2018 15:17:45 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41cjyD6Znkz3D2 for <dnsop@ietf.org>; Sat, 28 Jul 2018 00:17:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1532729860; bh=hdonZszS8hYVUDrnl/a541Mzbc52MwQ5mJASa4frM/k=; h=Date:From:To:Subject; b=WScdkC4k/qR4i1JV65fMc+mULnqdTOAUWbs0vVfMTK434wxcNgdiDZFHKs3sZsO9o UCD8C7uQmtlOcAJXSQYCs11u2ehoRT1UrYcQhfMXg+fXX97vcTkoSGmcCSTR3a6LtG EKGVpmJdW28ceSDs19OnSyu/QKtD6UH20v5I82c0=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id H7H4I7Cwc1OL for <dnsop@ietf.org>; Sat, 28 Jul 2018 00:17:39 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dnsop@ietf.org>; Sat, 28 Jul 2018 00:17:38 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 50B5B381FC8; Fri, 27 Jul 2018 18:17:37 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 50B5B381FC8
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 475784009E79 for <dnsop@ietf.org>; Fri, 27 Jul 2018 18:17:37 -0400 (EDT)
Date: Fri, 27 Jul 2018 18:17:37 -0400
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
Message-ID: <alpine.LRH.2.21.1807271758580.22024@bofh.nohats.ca>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/depyH_2Yld_fP3zgXLLMtW46bWw>
Subject: [DNSOP] zonemd/xhash versus nothing new
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 27 Jul 2018 22:17:51 -0000
On Fri, 27 Jul 2018, Warren Kumari wrote: > This can, but does not have, to be built into the nameserver itself. Those are just more arguments to not have a DNS checksum/sig option. What I see is that: We are looking at a way to distribute the root zone, presumably to make the root servers less mission critical and for enhanced privacy and reduced NXDOMAIN queries. We are depening on DNSSEC for integrity of the data, which just misses glue/NS verification. we can do AXFR but that would keep the root servers mission critical. glue/NS verification isn't needed normally, because we would just need a single working entry to pull the new root zone from one of the root servers - but then we depend again on the root servers as critical infrastructure which is something we seem to want to try and avoid. maybe this is also useful for non-root zones, so the method was sort of made to apply generically. I think the use for non-root zones is quite a different use case, so if I ignore that, we are looking at specifically the root zone only. What is the pain of getting a root zone file from an unknown/untrusted source ? - transport seurity isn't enough (so no (D)TLS) - detached sigs like pgp too annoying/hard? (two files instead of one, or the one file needs preprocessing before giving it to DNS tools) - we have to validate it with the known key (so some tooling needed) - glue/ns could be filtered (either a ddos, or a privacy concern?) - we cannot depend on finding 1 working root server and then AXFR it to confirm, assuming that would be too much load on the existing root servers (although load of junk queries would decrease if this is deployed) It seems the way to fix this would be to have well known recursive servers (8.8.8.8, 1.1.1.1, 4.4.4.4, level3, opendns, etc) also offer the root zone for AXFR. If you get something that does not work, fall back to standard recursive root zone queries based on the buildin hints file. We could also do some /.well-known/root.zone URI to allow for other https/tls servers for serving the zone without being a public resolver, eg for enterprise or isp network use only? Maybe a dhcp option to point to the location? Additionally, these servers could allow downloads of the root zone via HTTPS/TLS/etc for those tools that want to write a root zone file to disk for re-use or for preloading a resolver cache on startup ? In all of this, I don't see much use in protecting the root zone with either ZONEMD or XHASH. If the NS/glue is mangled to the point of being unusable to refresh the root zone, drop the garbage and do traditional DNS querying from the preloaded hints or previous copy of the root zone. If ZONEMD or XHASH was a regular record with no special handling, maybe it could be worth it, but it is a very a-typical RRTYPE and I think there isn't a very strong case for adding it to the DNS system. Paul
- Re: [DNSOP] zonemd/xhash versus nothing new Petr Špaček
- Re: [DNSOP] [Ext] Re: zonemd/xhash versus nothing… Edward Lewis
- Re: [DNSOP] zonemd/xhash versus nothing new Tony Finch
- Re: [DNSOP] zonemd/xhash versus nothing new Joe Abley
- Re: [DNSOP] zonemd/xhash versus nothing new Paul Hoffman
- Re: [DNSOP] zonemd/xhash versus nothing new Paul Wouters
- Re: [DNSOP] zonemd/xhash versus nothing new Paul Hoffman
- [DNSOP] zonemd/xhash versus nothing new Paul Wouters
- Re: [DNSOP] zonemd/xhash versus nothing new Evan Hunt
- Re: [DNSOP] zonemd/xhash versus nothing new Tony Finch
- Re: [DNSOP] zonemd/xhash versus nothing new Wes Hardaker
- Re: [DNSOP] zonemd/xhash versus nothing new David Conrad
- Re: [DNSOP] zonemd/xhash versus nothing new Petr Špaček
- Re: [DNSOP] zonemd/xhash versus nothing new Tony Finch