Re: [Add] some background on split DNS with DNSSEC

Bill Woodcock <woody@pch.net> Tue, 09 November 2021 14:59 UTC

Return-Path: <woody@pch.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 5D5C53A0DDA for <add@ietfa.amsl.com>; Tue, 9 Nov 2021 06:59:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 4QvuOpSzNgYM for <add@ietfa.amsl.com>; Tue, 9 Nov 2021 06:59:03 -0800 (PST)
Received: from mail.pch.net (keriomail.pch.net [206.220.231.84]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C3F3A0DE9 for <add@ietf.org>; Tue, 9 Nov 2021 06:59:03 -0800 (PST)
X-Footer: cGNoLm5ldA==
Received: from smtpclient.apple ([69.166.14.6]) by mail.pch.net (Kerio Connect 9.2.7 patch 3) with ESMTPS (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)) for add@ietf.org; Tue, 9 Nov 2021 06:59:01 -0800
From: Bill Woodcock <woody@pch.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_82CDB584-C74A-4417-B6B7-A2303DC8845C"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Tue, 09 Nov 2021 15:58:46 +0100
References: <yblk0hio8pu.fsf@w7.hardakers.net> <28611.1636465525@localhost> <3692CFBF-4D06-4960-9F7C-347A58D2D0A0@apple.com>
To: add@ietf.org
In-Reply-To: <3692CFBF-4D06-4960-9F7C-347A58D2D0A0@apple.com>
Message-Id: <ED83FE78-8F3B-47D1-BD8B-F3E57C947634@pch.net>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/qo1se7GR-Af7dQ2K3JloLJUKp0U>
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 14:59:07 -0000


> On Nov 9, 2021, at 3:47 PM, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
> Having a specific zone / subdomain that’s used for non-public hosts is certainly a clean way to handle split-DNS cases. This allows for simple techniques like failing back to some internal resolver when you don’t have an a priori mapping of which names should use the internal resolver, and it makes cases where you have a trusted list of internal domains (like VPN) very simple.
> 
> Sadly the reality of so many deployments is that there isn’t a clean cut for “internal” or “private” names. Maybe we can hope that deployments that use dual-facing or dual-resolving hosts will eventually stop, but I don’t see that happening any time soon.

Heh, Tommy just saved me a bunch of typing.  :-)

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.

                                -Bill