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

"Deen, Glenn" <Glenn_Deen@comcast.com> Wed, 10 November 2021 00:48 UTC

Return-Path: <Glenn_Deen@comcast.com>
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 BB1333A0DBC; Tue, 9 Nov 2021 16:48:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 (2048-bit key) header.d=comcast.com
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 GJsMBZf4WIRK; Tue, 9 Nov 2021 16:48:17 -0800 (PST)
Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 204EA3A0DA8; Tue, 9 Nov 2021 16:48:16 -0800 (PST)
Received: from pps.filterd (m0156891.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1A9Js049001059; Tue, 9 Nov 2021 19:48:16 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=lTPs+BUZt1JsDDOsm4oq9zngjOi6q+/ZEOiDHs2GIbA=; b=mw8mVMD/KfIEA1H++sso+tZjdT4vXsqv3dadwWYmdWVI+6+2pTrYyVlDcrBBIqG4Vvjq EigpxC4/yuIEkbC/zyzjwUaGWo/SVKSiEq2dn2P78vX153wbC4WuCwrOJ3wXhwsYaT8I qjV+mVdMK7HUUz2zrUOjRd1iPNTgRmApAHnr5ZyMBGjNITOSIXsmdDOqpZWHTdibhGTa iiu5o2fE0RL8SFxew5hOrxVJuCmmc9Y2KRzSHT461Fj+brLPMWQNZyKiW0/MjRUGBhTt 0AxbLfAGGXnVn5HI+19f9BO+saYrdAq3OMLfO/xKozEyH3SdbAuwaOkJ0o1FO9DBIvCJ Xw==
Received: from copdcexop01.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0a-00143702.pphosted.com with ESMTP id 3c7qq7pvcb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 09 Nov 2021 19:48:16 -0500
Received: from copdcexc33.cable.comcast.com (147.191.125.132) by COPDCEXOP01.cable.comcast.com (147.191.124.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.2.986.9; Tue, 9 Nov 2021 16:48:14 -0800
Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15 via Frontend Transport; Tue, 9 Nov 2021 17:48:14 -0700
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.105) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1497.24; Tue, 9 Nov 2021 17:48:14 -0700
Received: from BYAPR11MB3111.namprd11.prod.outlook.com (2603:10b6:a03:90::25) by BY5PR11MB3912.namprd11.prod.outlook.com (2603:10b6:a03:190::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.13; Wed, 10 Nov 2021 00:48:09 +0000
Received: from BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::617f:e771:6c58:7d3d]) by BYAPR11MB3111.namprd11.prod.outlook.com ([fe80::617f:e771:6c58:7d3d%2]) with mapi id 15.20.4669.016; Wed, 10 Nov 2021 00:48:09 +0000
From: "Deen, Glenn" <Glenn_Deen@comcast.com>
To: Paul Wouters <paul.wouters=40aiven.io@dmarc.ietf.org>
CC: "add@ietf org" <add@ietf.org>, "Deen, Glenn" <Glenn_Deen@comcast.com>
Thread-Topic: [Add] some background on split DNS with DNSSEC
Thread-Index: AQHX1a3bx4mn7M+74EqzoswY1Q1Kc6v70kqA//+VfwA=
Date: Wed, 10 Nov 2021 00:48:09 +0000
Message-ID: <183ABDCE-6E9B-4E66-A319-4CB2DF5445A5@comcast.com>
References: <DD51ECDC-9787-4DEB-A2AF-39C3CF2ABEE8@nbcuni.com> <c999a1c7-a8e-2f94-10f9-5342ff4fc696@nohats.ca>
In-Reply-To: <c999a1c7-a8e-2f94-10f9-5342ff4fc696@nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.54.21101001
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=comcast.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 22b2b87b-48a9-4eaf-0914-08d9a3e3c427
x-ms-traffictypediagnostic: BY5PR11MB3912:
x-microsoft-antispam-prvs: <BY5PR11MB391234409A5040E576DBFB8FEA939@BY5PR11MB3912.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: kEZCP5WOqrvJJ5cAf8rQEH1/Euf8CUq6/PqOImyOfO1XFPLlrYZLLdiedmHG/p0OT7ZKo8mIl795rkCNY5oPMVdKmv6FZxmgIF5HvvhQyQz7sjWiPqcSxdRw5RLZAZeuN4L57SW3lz90/OdlmPYWPpH18eQnQy8190pZjO1mGUVvm8g+Bh61xYvRAYwM7p07jlTV6qOFjt6QcmPU9jtXKHG+cBRiVFYPrNb5bjdscys7WANmgj1tDyPHP84o/9D6S1a8LEMBKI300Au8ZyoNsDQWOm0dG91j2T2e+SAoensF9WoEjVvg4pmBfCY30dAFjHAyHtkdytwP4cbf8b1+o/h/6kTIpyh8gDYy9cDG0Ac3jVGDGSU3kiolBUNexndO5TTu3E9y20bl7O8NMt6brKm+Ga+/7W5PntfRt+7X39xOEAaeORa04eUmizr8fATXX8CR4kDtK0NlceI1tgJ4exCCdVWAK3tRMbcu4tk7pJ1J9bhOkE2QKmJx2nQZcxXPMK+wbmCDWnGFH07yNOmt8nYQAPCQLnqLtku04/Ho93k5oh1SPa65aizAEVsmoXS8vKC5YFoSq6/mUP1YKQzg64Ih53/crG0HBN7V8hid8VHkv5dec+Q6p4xxI489YWnhZyNgDH7SqmMrSXVgNJl7Q2uZKP/JqtByGiisYNt7QaNNu7C/fEqI7q5laVf+ovzkMRe2AD0EmuI8LxwpYeCu3NZXf6O7VtDXh29PjWEO3wO0/RJsWoaDbNKoyAN+Wlzl
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3111.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(84050400002)(508600001)(66446008)(76116006)(66946007)(64756008)(66556008)(2906002)(82960400001)(107886003)(66574015)(66476007)(6512007)(6486002)(186003)(316002)(36756003)(83380400001)(86362001)(5660300002)(71200400001)(33656002)(4326008)(8936002)(38070700005)(38100700002)(6506007)(2616005)(122000001)(8676002)(54906003)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: AXVBYArB2jonn1sJoxDzNyfs3S76LPFsajz2zPpzvPSYkdXG8G8PHHrg12yxmgQ0u0/mR1dr8yZdkbhmilp3bqjsYq9KLiSqlFC8D1z6HkgX4GBCATh+PZ7Ec7BHpp87NXFMCWHlBMX18EqkIrAoPy9Q3FCdUvkl/l6ybTz9tLq99Sk5jcvKTkxw5Eue/tyoC40hYaK9PRHtcoA00qZwhmt4Lu3JkXpkFf2zILTkOM5Qp9NU+YOjiMAK1r4aEymyPKvp/2ZTI8nqdbd089GUis6nzpmuo2eGeIoUO7aWILueT5uC5tmi12gWNCIutbOe2xb7Wi0+1L/52F13HjSzxeqnrEK58NXjPI+2gHaRykDBGvzqNZJorB67CUglIWvkAuINeJQco+hl+XmIIGhOgyhegCPtIpGdlvVMf1VTTFrGz1E5J0Bd7N8u5PuKLOMMOPMMfYVwvOsuTkZQgRly/KBEbeuOvJu/ZCCZB8xRnIDzEKtJ9yX0ZA5fEmQET6ya2Wl8gwCAmnnOCqrOtM8glpN8VfBAO6/A1hQPa0KNs26IBp9fj7R5feX0f9Z14zUkNa2X7uJTqdgDPbdo4ejOnRTop+DD9QA48inZy9bTKXnmQJaOmuHlz11ou6E1l2GGYd/AMPneopVALrTdX09k3p56naYL+SziFnt+kqwQjyMgVHkQ4c1ZQ//MnbBmrQ6olpkSBr6k712CM08BRHkyL0axK9IG4XJXaAzanO0v0ru+rQbG18v8XY0WGtN0ugZ23Tg+pj8VXgAJcoNtVtmgZpHpe7cZFfNX6v2SqTKdydF5HyvAiQzK7Xv2+HpGWC6ujS04P8L6Tn2VnlG3Dq7MkZsD+MieH5sECyIHwPeYsaRSOGlhjOe1D9xzg2TEWFYMfMN58ml5A7H4WJsrSQdlmA+08BqDYuouq3ublhdZ7PpWGRyBhsMpUd2/nZJxYyoIrPHGNh5i4L0f42ZwgJaxp07tjkLJYdWCkLAZD762V7YR6l526uDhCvrNx93D+nTTfXiGWQDdc/FyC4oGFQGBGFRxcLI5c7GJRzvm5URC8tNI6j8A7MQWNykchBTkUdzEYZWZeiBd+Liz3PMPQjUuc8iCEB9n3xX4m+Qv8DS4viHYd42fClroGrqUzGLwEJR7xiwa+pvdJ/flnOm/Hiv5PPYmWtByMZy6uY7jkD34uRWbDt5TIkPzvkgIw2DO+JKXHEnS2THXsusUhG82ueV5EQ4UnOeh+X8oU0uEanDPXuhEkPw/6f4xgQTue/K0Qafr5heA+/g8ISKRCtC3ixahAJT1MZp+Mv+1+TOS5gmT6yIZJMQV+PhrBlzv31A7T6ZdrqrutavoM7mVz9VfWaM/xvxwUq2o5gwK/wC5uq9dv+sQuugh7JHLYvXNgOJm8TzoMWhvCvK2Ul2N9hKpOpagp3kfhZErIMjWDC2beMFpFT96GTq/NzfgV0wAU5W3GxT2vAXVQF724uiCdTBhBcr2mDM/+HZF25VFlQ+ak6TG1WS7nmzm+jDIev0Ke6kQT4xXFTeWYxFQRuQoMlV7QaTMlYIPoOFNTnWR1Dtl/Ai9P6C9Df4nlYIVyq7KUCXjYHRFxs2xL1w01PwUxMG6Iu+Higkh2Ucd2A9Bu06XcU3/SFUmnyzDSdvxnj+fCAHRxFwGQSjzG6Sr5tc7bgYXtvjKuq8OAjShqVs7H9Xz3xy9NGDEHkok07eIeD4VGc/FUvLyd4ib9CZ3B8R69jCIUZwKCnLOZzc4PTKUxMkrwdKn5vI=
arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g307jg1bAe3aV8txSPGBVFLpbLzmQJp/f65/V67q4eiX+2EiBf1Jakixf9rJ5Hasc+rPeM9ibHMg4YIoaI/nSP3n8DuLE9wW0DAFPj8/MnDMFfWZwGDJ6RRZzWNimOC8f9co01RyZJ2tLo4VVRPQkvIircYB17XXNHr/dUwJ/vX+EOP0dRQQodoun/esfhD1bjiZaWQhd9s72gOC6qeTiZpP15ebyE2OBCDQsaQMMC5+kYHWJb0H0B/0z2L1HbEFqFglXcEAc/RufvT6Jzux6TIuTz4+fjtjdKP1oQZb2xsoDIHKRuTr4vFQqcsNqWm566ltccHIjkjeBOno07KoiA==
arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=d27plRJfxKyWyrIvVZTDWp5ioYFtUzO1DbqIKmVuyIc=; b=oWyVklWv/Y4T4ZjMMK1HXM9xTe4SC+CnW5WdHlAoFH2xCl7qZEweT2XWNUB2BQwrH/ShhavxDfZTQNvpTQXqZtiHPOoY0/TJCuCRSviqS4ZPiCGrY3S11dVZ/sbBbUP0kmlYqV2H2T73yQp9w7quV60Y7k9Sf8r96AcyQKk5eG5SvPtJHuEkkyngU+ZP21v/hX+wkJ9HNBAl3B/CLYcSXcccDPsd6e2/Be1/tFAI3OWugAGOvDy47Q9ciOT7ZfrmD16DldwOl6EztLn7B7p1w7RdPrFkyeOWQ+mouoCiPiyPqVnX4wSIAOgpn6FRaP9S/+3QJubIFlmKQWfiZGTbOA==
arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none
x-ms-exchange-crosstenant-authas: Internal
x-ms-exchange-crosstenant-authsource: BYAPR11MB3111.namprd11.prod.outlook.com
x-ms-exchange-crosstenant-network-message-id: 22b2b87b-48a9-4eaf-0914-08d9a3e3c427
x-ms-exchange-crosstenant-originalarrivaltime: 10 Nov 2021 00:48:09.1483 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa
x-ms-exchange-crosstenant-mailboxtype: HOSTED
x-ms-exchange-crosstenant-userprincipalname: XhqZyL3orN5yWTcyRaSk6KOcWXCBG6sHiXjjBeIvcIJEXWqNnHEeiyXMT+Q3cp/DQX6jenMOJjvVtgN9z1wK/u3qwQXTZbQjf11L+ntmqJQ=
x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB3912
x-originatororg: comcast.com
Content-Type: text/plain; charset="utf-8"
Content-ID: <8DB770B7855E994B8246650CE8CEB8FE@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward AAETWM
X-Proofpoint-GUID: sjlumxek7I5j1umi0HJirCoEQlajATjW
X-Proofpoint-ORIG-GUID: sjlumxek7I5j1umi0HJirCoEQlajATjW
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-11-09_07,2021-11-08_02,2020-04-07_01
X-Proofpoint-Spam-Reason: safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/zB1f6V_z7Clyvc3fF3gmVjkz9Uw>
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 00:48:22 -0000

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.

The nuance, and why ADD has a couple of different documents on how you discover is that there are a couple different network environments that this discovery needs to work in. These are driving entirely by what the users live in today.      (1)  DDR covers when you can find resolvers by going to the DNS and looking up SVCB records. (2) DDR covers when you are in a DHCP/RA situation.   (3) CPE forwarders and finally (4) Split DNS is when you are in a split network environment where one side is "private" and the other isn't.

If we focused on the question of the split-dns/split-network case, and don't pull in the various DNS zone, authority, visibility, leakage issues which are IMPORTANT, but outside discovery of which resolvers there are - what is the right way to find DNS resolvers for (A) the private side and (B) for the public side.    Why isn't it as simple as specifying the way you do it on the private and the way you do it on the public and punt to other work the other questions?



-glenn

On 11/9/21, 3:09 PM, "Paul Wouters" <paul.wouters=40aiven.io@dmarc.ietf.org> wrote:

    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