[Add] Why so complex? (was Re: some background on split DNS with DNSSEC)

Martin Thomson <mt@lowentropy.net> Tue, 09 November 2021 15:25 UTC

Return-Path: <mt@lowentropy.net>
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 C1BF93A086E for <add@ietfa.amsl.com>; Tue, 9 Nov 2021 07:25:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=M10Eh6EF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bprxF/yb
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 fuXLQgH6q0-9 for <add@ietfa.amsl.com>; Tue, 9 Nov 2021 07:25:43 -0800 (PST)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982823A040A for <add@ietf.org>; Tue, 9 Nov 2021 07:25:43 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id E46F53201CAD for <add@ietf.org>; Tue, 9 Nov 2021 10:25:39 -0500 (EST)
Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Tue, 09 Nov 2021 10:25:40 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=74f7l du2XIefW0AXRS4hRbq4kYg1TSYzQVwLec7/2W0=; b=M10Eh6EFhU5X6cb4mVzLY RPTANARO3Ezgzv9adrhYlbVB8A252Oo1DQsfyW9rutR5rQfy9ECiD6oe+BlaN7V2 6fhA4Ncy5mKj9fHaXpQMBTyp/eDXlybJup6rN4zjNdB3zAdy0UmM5a8cA1QYh5ZS 359EkIDj0ttETzOKiP/aRNO+RrLLX4SAt1Cn/W53iQD5hyS19/9W/7FQRs407Rma yFUVoqZG1HA80Qdze9qwXXaUu3i9wuyoD1THRj75oNDoubMm9BrsMfbqw/99KoKg yIsWBjckEolknHYLlUybJRoLi6723SA008HJ2/crGE7XJuhnOl8lwwvNxB5CEDdJ Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=74f7ldu2XIefW0AXRS4hRbq4kYg1TSYzQVwLec7/2 W0=; b=bprxF/ybXvky5/TSvp6Qidxw8MqtbKdUNql15B5EVau96ejmG6/ja3Cjw bQKnhZueFOc12Jkz0T3BosageESCOeOi65YmPSi2sC5i78M6Xw8skNrxn02mIWgy VmHcNVmSmcVgmDc4E2l1eFCs6CQBloKedpGgTHjHMf2uTVs/PjVwRYlVgIap54YL IksoaajJE/sp3rZdno+LWIJVr0G3nyi60OhryVD8iEjQYVJgm/MIzbbZFKJ65+c/ CIQ4TcGP3O+8mIU5Wav/RtEBLicr44bxTPWFbL0tnR/9EtzkKTFY5BAMDVnyPSGN nsMi0IWLCMqvhj2ugHRy9GVJNhR4A==
X-ME-Sender: <xms:85KKYVX0hvByaUGJzWlP0Yqr1d_e_x9foJFmm6g84zLwDcN6joKd3Q> <xme:85KKYVmCTOXoUvLEx-9gspRkLGU8Dg8uQyF_fwuCXK2ov6D95agGuRfZNdh5Pqgc0 iiwpn4Jne0nEhGBUo8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudeggdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefgjeeuudeiffeltdegle ehjedvtedtjeduudehgfegfefgkefgueeiteegffdttdenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht
X-ME-Proxy: <xmx:85KKYRbOG6610AmptK_Csj2stukJnMrFvHke6xQFffF52pT7eV3jJA> <xmx:85KKYYXvKXIm_EYBKY6XeTTVTPmrgg4DHQAj7dEWgH-xQepTgNCkYQ> <xmx:85KKYfk97KnTtv5npJ3WaLObBcwheIwx9gokmsqTWHjFJp6nlOwADQ> <xmx:85KKYby0v3qZjw0nw9zvUrcobC_zYYqiMdTlIrEr3da-1uLV-YI6Cw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4FE663C0C77; Tue, 9 Nov 2021 10:25:39 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1371-g2296cc3491-fm-20211109.003-g2296cc34
Mime-Version: 1.0
Message-Id: <125f8deb-e662-4325-a7ce-6f7c2c2f9992@www.fastmail.com>
In-Reply-To: <ED83FE78-8F3B-47D1-BD8B-F3E57C947634@pch.net>
References: <yblk0hio8pu.fsf@w7.hardakers.net> <28611.1636465525@localhost> <3692CFBF-4D06-4960-9F7C-347A58D2D0A0@apple.com> <ED83FE78-8F3B-47D1-BD8B-F3E57C947634@pch.net>
Date: Wed, 10 Nov 2021 02:25:12 +1100
From: Martin Thomson <mt@lowentropy.net>
To: add@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/VAxieIQcFOnBXmOlsv_-fgHQ5yI>
Subject: [Add] Why so complex? (was Re: 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 15:25:55 -0000

On Wed, Nov 10, 2021, at 01:58, Bill Woodcock wrote:
> My observation is exactly the same.  The problem isn’t so much that new 
> organizations will decide split-horizon is a good idea, as that old 
> organizations have grown very large while doing it, and have decades of 
> momentum.

My concern is not whether split DNS exists (it does) and whether it will continue to exist (it will), but what the security goals of our work in that area might be and how those might be achieved.

We know that under some conditions (to be determined), some clients (to be determined) might wish to use a particular DNS resolver (varying) for some - but not all - names.

We have already determined that this is not something that is exclusive to Enterprise, as much as the practice is widespread in that sort of setting.  We might also want to consider whether the goal is to use a network-provided resolver as opposed to a VPN-associated resolver or a company-policy mandated resolver.  The split-dns draft proposes that we address the network-provided case, but it proceeds on the basis that the policy that causes this proposal to be used is limited in terms of what is configured and then also very specific about the security posture the client adopts as a result of that.

The whole thing with checking a public resolver is all in aid of something about ensuring that the network resolver is authoritative in some way for the names that the PvD claims should point to it.  But this all assumes greater and greater trust in the PvD and - by extension - the network.  And I'm not even sure that it is operationally feasible.

If this were a company-mandated policy, why could that policy take the form of a resolver identity and a list of names for which that resolver is used over all others?  For simplicity, this could be just be a URL for a policy if updating is important or the number of things to configure is unwieldy.

The advantages of that approach are many. For example, when some software pings the internal host accidentally, that name doesn't leak if the host happens to be somewhere other than the office.

If this were a VPN, the same could be used.