Re: [Add] some background on split DNS with DNSSEC
Paul Wouters <paul.wouters@aiven.io> Tue, 09 November 2021 23:09 UTC
Return-Path: <paul.wouters@aiven.io>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217E33A0877 for <add@ietfa.amsl.com>; Tue, 9 Nov 2021 15:09:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io
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 tIz6LHwn8ZVR for <add@ietfa.amsl.com>; Tue, 9 Nov 2021 15:09:25 -0800 (PST)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9C03A0867 for <add@ietf.org>; Tue, 9 Nov 2021 15:09:25 -0800 (PST)
Received: by mail-ed1-x529.google.com with SMTP id f8so2847390edy.4 for <add@ietf.org>; Tue, 09 Nov 2021 15:09:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=uTmLEzgEPNRUEeGG3jhnFI9/jtTny3dR/YX5cx6sYjE=; b=M59Kch1NYCsS5tKqnEDjhdirbpecElfcYLdBtG2oyOrue3zkbcN4YPnrZx4lvJotsq XV6iB5BYdQOm3bl9WC0Q5hpa9NFETavbvSqc17GdrI4couj4LrnfLg3jdrDOecjJIb6H VImYIdecJiogvgZnJ4xjBI9cONab9STmc14D8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=uTmLEzgEPNRUEeGG3jhnFI9/jtTny3dR/YX5cx6sYjE=; b=P7MK96zsH2VHjZD7qsbLVlKMdzrbSopkQPrIVhyz6d4AR08MGa+YHlr9+EGjMWpD60 XKZUyBaBxFSVw2IUx74E34bMFcRXCZ54UT8SbsJy3ILTe+b+VbkmwryKue+WfoYVD0QC vkrfURreQAPFZOWsKfC1WTkbe1sFe0Epbg6ncT9L4XUXPFdOXs1XI/oTvPa1z32DufPN yOEiI3B4iIMJfERSWW/o9GtYGI97gnDt86vpEpEXjVYqPgHcMPFNlCZZCnSy7PI8MKF2 93YXsQW+AWvEkIqjp9motQJvvDgKSj6xXuK3RLOCJaD+MyxkvrcOQ5eNQ3ENHxWb3nxd KlYw==
X-Gm-Message-State: AOAM533SpC+ugzwBT029bfsEa6nVDBk1SydB4ctRugmzW9PdDylDAMob zvgspEnHXm5qGJqpCq/9OUWLJU7MH6K+81YP957O6A==
X-Google-Smtp-Source: ABdhPJxasoR6CGcuB6QYRWNCFclmZJahlp56DHg9P4x/9kmQigisuJPAcx8Kma+y1JyL0w1oCOFZlg==
X-Received: by 2002:a05:6402:4252:: with SMTP id g18mr15129234edb.399.1636499362733; Tue, 09 Nov 2021 15:09:22 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca. [193.110.157.194]) by smtp.gmail.com with ESMTPSA id s3sm10339902ejm.49.2021.11.09.15.09.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Nov 2021 15:09:22 -0800 (PST)
Date: Tue, 09 Nov 2021 18:09:19 -0500
From: Paul Wouters <paul.wouters@aiven.io>
To: "Deen, Glenn" <Glenn_Deen=40comcast.com@dmarc.ietf.org>
cc: "add@ietf org" <add@ietf.org>
In-Reply-To: <DD51ECDC-9787-4DEB-A2AF-39C3CF2ABEE8@nbcuni.com>
Message-ID: <c999a1c7-a8e-2f94-10f9-5342ff4fc696@nohats.ca>
References: <DD51ECDC-9787-4DEB-A2AF-39C3CF2ABEE8@nbcuni.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/cc1e8e4EDugSDYrodeVJeVjua_Q>
Subject: Re: [Add] some background on split DNS with DNSSEC
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 23:09:30 -0000
On Tue, 9 Nov 2021, Deen, Glenn wrote: > That said, what ADD is chartered to do is to look at how to do encrypted DNS resolver discovery in the environments that users do live in, and not just environments that we think they should be in, so with the background on DNSSEC that started this chain, and EKR's moment of actually putting a good word in for DNSSEC during the ADD session, does the group see there being a role here for DNSSEC? I think the problem is still that the different use cases are conflicting. 1) Enterprise split DNS Use provisioning tools to get similar security as RFC 8598 with authenticated list of domains to take over. This would avoid using public DNS to "verify" or "authenticate" which would leak private enterprise domains. I think the current draft's text of somehow (still unclear to me) have public nameservers claim authority for internal only zones is the wrong method. Signal some URI over DHCP options and let clients with provisioning retrieve/verify/use it. Unprovisioned users would not use the option, lacking a method to validate the list, which also prevents abuse of this protocol in non-enterprise setups. 2) ISP like provisioning domains and hotspot (redirect) domain logins This is the hardest one, eg .box for the Fritz!Box router in Germany. In this case, it requires accessing .box, but it is completely squatted. You could only allow this if you confirm the external domain does not exist Also, germany would go offline as soon as .box gets delegated. We don't care about leaks here, which is good because one has to query the public DNS. But as ekr pointed out, browsers already have a workaround behaviour by trying public DNS and if that fails retry on local network's DNS. systemd-resolved sends out the query on all interfaces (and uses the first returned answer, which is in itself a security nightmware, but I digress). The question is, is this something ADD should take on or leave out. I think it should leave this out as it cannot in a reasonable way be authenticated and/or authorized. 3) enduser protection mechanisms I don't think these would be advertised as domains to resolve but rather would use mandatory use of DNS servers that would filter these. I have been at a hotel chain that blocked priceline.com. Coffeeshop wifi might prevent certain domains to prevent things like Google Meet or other domains that make people use a lot of bandwidth and stay very long. Schools might grab facebook to block it. While I think network owners should be able to dictare terms on their clients, I don't think the current ADD split-dns is the right mechanism for that. And then we have the issue of this document of split DNS having a run-in with censorship, either by nationstate or as a security service. In those cases, the goal is to take over all DNS for the protection of the user. When that happens, it overrides the split-dns network configuration. But of course, enforcing of that is impossible and a race of DoH against the administrator ensures. I did see the Zero Knowledge Proof DNS blocklist presentation today, but I also feel that even if the protocol managed to be speed up to be usable, the problem is that those who want to deploy blocking as a security service would want to know which domains were queried (eg to detect the C&C domain to identify the specific malware running). Those with the power the censor DNS don't often want to give the user full privacy - especially when they do things that are not allowed on the network. I think the one real use case here is to fix is the enterprise list of domains. This is the use case where every party agrees to play along. If I need to access internal.aiven.io when I join the wifi and use my own TRR nameserver, I need to get these domains into my application. The current browser method of trying external before trying internal nameserver fixes that but it is not the best solution for all applications performing DNS. My laptop's build system would fail with DNS in git or other build tools. The browser solution also does not work when the view leads to different valid result. Eg if vault.aiven.io would be landing page with "nothing to see here" on the external view, and a real vault on the internal view. The easy fix is "don't do that" but there might be more complicated scenarios where this cannot be avoided. Putting a solution in the stub would be good. I think ADD can specify something here, but it would really be part of (and authenticated by) the enterprise provisioning. Which could be as simple as a URI via DHCP option to a signed list by a CA that I installed. I am not sure dancing around in different DNS views would be particularly useful. And it would still allow outsiders to see those public DNS queries which are supposed to remain private. And I still don't understand the updates to the document from this Monday, that adds some packet flaw images, but no DNS query information. I still don't understand it :( Paul
- [Add] some background on split DNS with DNSSEC Wes Hardaker
- Re: [Add] some background on split DNS with DNSSEC Michael Richardson
- Re: [Add] some background on split DNS with DNSSEC Ben Schwartz
- Re: [Add] some background on split DNS with DNSSEC Joe Abley
- Re: [Add] some background on split DNS with DNSSEC Tommy Pauly
- Re: [Add] some background on split DNS with DNSSEC Bill Woodcock
- Re: [Add] some background on split DNS with DNSSEC Eliot Lear
- Re: [Add] some background on split DNS with DNSSEC Ted Lemon
- Re: [Add] some background on split DNS with DNSSEC Bill Woodcock
- Re: [Add] some background on split DNS with DNSSEC Eliot Lear
- Re: [Add] some background on split DNS with DNSSEC Bill Woodcock
- [Add] Why so complex? (was Re: some background on… Martin Thomson
- Re: [Add] some background on split DNS with DNSSEC Eliot Lear
- Re: [Add] some background on split DNS with DNSSEC Bill Woodcock
- Re: [Add] some background on split DNS with DNSSEC Jim Reid
- Re: [Add] some background on split DNS with DNSSEC Eliot Lear
- Re: [Add] some background on split DNS with DNSSEC Bill Woodcock
- Re: [Add] some background on split DNS with DNSSEC Eliot Lear
- Re: [Add] Why so complex? (was Re: some backgroun… Paul Wouters
- Re: [Add] some background on split DNS with DNSSEC Paul Wouters
- Re: [Add] some background on split DNS with DNSSEC Joe Abley
- Re: [Add] some background on split DNS with DNSSEC Deen, Glenn
- Re: [Add] some background on split DNS with DNSSEC Deen, Glenn
- Re: [Add] some background on split DNS with DNSSEC Paul Wouters
- Re: [Add] some background on split DNS with DNSSEC tirumal reddy
- Re: [Add] some background on split DNS with DNSSEC tirumal reddy
- Re: [Add] some background on split DNS with DNSSEC tirumal reddy
- Re: [Add] some background on split DNS with DNSSEC Dan Wing
- Re: [Add] some background on split DNS with DNSSEC Dan Wing
- Re: [Add] some background on split DNS with DNSSEC Wes Hardaker
- Re: [Add] Why so complex? (was Re: some backgroun… Ben Schwartz
- Re: [Add] some background on split DNS with DNSSEC Joe Abley
- Re: [Add] some background on split DNS with DNSSEC Ben Schwartz
- Re: [Add] some background on split DNS with DNSSEC Michael Richardson
- Re: [Add] some background on split DNS with DNSSEC Michael Richardson
- Re: [Add] some background on split DNS with DNSSEC Bill Woodcock
- Re: [Add] Why so complex? (was Re: some backgroun… Bill Woodcock
- Re: [Add] some background on split DNS with DNSSEC tirumal reddy
- Re: [Add] Why so complex? (was Re: some backgroun… Martin Thomson
- Re: [Add] some background on split DNS with DNSSEC Ted Hardie
- Re: [Add] some background on split DNS with DNSSEC Ben Schwartz
- Re: [Add] some background on split DNS with DNSSEC tirumal reddy
- Re: [Add] some background on split DNS with DNSSEC Ben Schwartz
- Re: [Add] some background on split DNS with DNSSEC tirumal reddy