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

Paul Wouters <paul@nohats.ca> Wed, 10 November 2021 01:18 UTC

Return-Path: <paul@nohats.ca>
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 E116E3A0E1D for <add@ietfa.amsl.com>; Tue, 9 Nov 2021 17:18:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_NONE=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=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 5RlKKIP-5S31 for <add@ietfa.amsl.com>; Tue, 9 Nov 2021 17:18:07 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.85]) (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 47FD63A073D for <add@ietf.org>; Tue, 9 Nov 2021 17:18:07 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Hpn646LTpz3Yf; Wed, 10 Nov 2021 02:18:04 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1636507084; bh=nMYsZAfNYhGnYyCKFeV8FsAY7L0Wv4SCF2RgCxU8S5I=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CRytYguHAnACKRYQYjAagyCbbBkNidNEKryVpd8kNsOvk/6AN84LuZo3KAECmDnmf czTASv4IkwEp4GQOMxtvLrJ+wN1RYIAO+LauFO6kKGXjQtvP71bKULjWfcvDvAvr4z JqDETpHuE0ieqar9NraujqIZUWftS95P293doXsg=
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 ZWriKnimh41z; Wed, 10 Nov 2021 02:18:03 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 10 Nov 2021 02:18:03 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id F0440132DE0; Tue, 9 Nov 2021 20:18:02 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ED720132DDF; Tue, 9 Nov 2021 20:18:02 -0500 (EST)
Date: Tue, 09 Nov 2021 20:18:02 -0500
From: Paul Wouters <paul@nohats.ca>
To: "Deen, Glenn" <Glenn_Deen=40comcast.com@dmarc.ietf.org>
cc: Paul Wouters <paul.wouters=40aiven.io@dmarc.ietf.org>, "add@ietf org" <add@ietf.org>, "Deen, Glenn" <Glenn_Deen@comcast.com>
In-Reply-To: <183ABDCE-6E9B-4E66-A319-4CB2DF5445A5@comcast.com>
Message-ID: <45a729d-3e59-f21-2498-fdd419227352@nohats.ca>
References: <DD51ECDC-9787-4DEB-A2AF-39C3CF2ABEE8@nbcuni.com> <c999a1c7-a8e-2f94-10f9-5342ff4fc696@nohats.ca> <183ABDCE-6E9B-4E66-A319-4CB2DF5445A5@comcast.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/67tJJMllA80HK7JSrRGR1syLFxA>
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: Wed, 10 Nov 2021 01:18:12 -0000

On Wed, 10 Nov 2021, Deen, Glenn wrote:

> Top posting as there is a lot here, but I’d like to suggest maybe the path is carve out the ADD task and tackle the other issues elsewhere.
>
> ADD is really about finding what resolvers are available and acquiring info about them.     The rest of the problem space - who's authoritative, leaked domain names, blocking, etc are all outside of the ADD mission.   Find the available resolvers, get info about them.  That's it.

If you go that way, then I think you would only need an option for
DHCP/RA to convey a URI about where to get the list of internal domain
names, and let the URI specifics handle the authentication (eg via
HTTPS). But that would be a different draft.

Paul