Re: [dns-privacy] [Ext] Opportunistic encryption between recursive and authoritative servers

"Brian Hartvigsen (bhartvig)" <bhartvig@cisco.com> Mon, 14 September 2020 21:44 UTC

Return-Path: <bhartvig@cisco.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB853A0A25 for <dns-privacy@ietfa.amsl.com>; Mon, 14 Sep 2020 14:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=H4rfk4Qp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XAkdGKdr
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 iuD_-IrTA87g for <dns-privacy@ietfa.amsl.com>; Mon, 14 Sep 2020 14:44:23 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A643A0A1E for <dprive@ietf.org>; Mon, 14 Sep 2020 14:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5814; q=dns/txt; s=iport; t=1600119863; x=1601329463; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XtZH0JQbT6QqyvE/V3d8y7RiclR1jYrA0clOJv7kUqM=; b=H4rfk4Qph2Bvk+WRIVm1x5C8f5aX6knG/rT//n2Z0z1v3cEZwGHb3Lew 6czlYeL5LAXgxvili7KmADEorIDnfc67kSZDyGa8umDrCMsarx22I72R8 z25PbtCH4lBMn+nxNLCC5CAT362AWVExa/eOQvLLilJydmoEzmW5loHvE Y=;
IronPort-PHdr: =?us-ascii?q?9a23=3Aomah8Byon+KDoG3XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWDt/x1il7CG4PW96EMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iKyKU5UE4D4akGB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8CQAv419f/5hdJa1gHgEBCxIMQIM?= =?us-ascii?q?hKSgHcFkvLAqEL4NGA41vgQKXcIJTA1ULAQEBDQEBGAYPAgQBAYRLAheCEQI?= =?us-ascii?q?kOBMCAwEBCwEBBQEBAQIBBgRthVwMhXMBAQECAQEBEBERDAEBJAgLAQ8CAQg?= =?us-ascii?q?ODAImAgICJQsVEAIEAQ0FIoI5SwGCSwMOHwEBDqtOAoE5iGF2gTKDAQEBBYE?= =?us-ascii?q?zAYN8GIIQAwaBDiqCcYNpgkGEERuBQT+BESccghg1PoJcAQGBXxeDADOCLY9?= =?us-ascii?q?mJyqCcKNjCoJliG6OZ4JoAx6DCYl1k26SXopWlQ0CBAIEBQIOAQEFgWsjN4E?= =?us-ascii?q?gcBU7KgGCPlAXAg2OHzeDOoRZO4VCdAI1AgYBCQEBAwl8jRAtgQYBgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.76,427,1592870400"; d="scan'208";a="575884484"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Sep 2020 21:44:22 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 08ELiMov014308 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Sep 2020 21:44:22 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 14 Sep 2020 16:44:22 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 14 Sep 2020 16:44:21 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 14 Sep 2020 16:44:21 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A3P1Dm7JcqmBaxYoht7NWdmbX0HJg/pby78/usDZSGrcFg6sDNnioaLxE1NEBEnCyr8Sso+Pa3Grq0r9fiIXWc95POY9AIUWVQUcVRGYJbqnv0jsxAiWoulHWW0dCd/veaWV6Q7rRCnKW2LYekm9CiOskRvUPU+LFGXGEZT6MPYS8L/a0o1XS1176y0+dX4LrsA8ACYFNVsI4GNxJAHDGaCzUWcLUHuHfJsZNfzKWvGD+bPvpxPHT9T+zYiDUlMSIjOTl4Bqn8OHqbeO34tq2SFNquNJZWCUZjDDGBzkcjQDrAPCm/8GDYobSSVIevz1qJl1MmhZl6Py5Mn/xjoivA==
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-SenderADCheck; bh=XtZH0JQbT6QqyvE/V3d8y7RiclR1jYrA0clOJv7kUqM=; b=PbTgwEsmO8fpOo3+d1wRlLBfjz3v3+jtHHApo7IxzU4cdSgP7+Lwvt5uOWls30Pt71krgNH4rwGfZMI3SLTNL+I5C7B49EFSgbJGCp4bzrDkDKwpUNXSUAxHQXZ3QzYBJm5FGzhTZlbm0apBdVMr7+2VGDJ604ihgY4CYKXg3X8em/POSR1ahQ2EJqM50PftyHB7Wk7Jbxdqgs6bIy0cL3A+geHrWBVX6Sc8MhAr5bYOY1n4pFzitT3JNhMCyTlG2aQ1XHA+shihJh2rl5Utv5ympxgKZvcVN7BveoFWdfoVuKjpcZJTqk3bkakDgdvvHSAb3nqLoS4IbOJPAKhBLA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XtZH0JQbT6QqyvE/V3d8y7RiclR1jYrA0clOJv7kUqM=; b=XAkdGKdrQqMRcPFMO4bBSQPV3xXqQ/Bmf6w6JnVGBlAHSN1hDz54N4em/Ut0l45RqxVrRNO+owtIKm4agCbwFD1s+wBwlwvhBk5SEPGStw1TjzqYR6lHbBEXZeDTQ19jiOWMyk/UohGhHNAi7dsppdDKLeDT5yr2phRc5ddsXTg=
Received: from MW3PR11MB4763.namprd11.prod.outlook.com (2603:10b6:303:2c::12) by MWHPR1101MB2110.namprd11.prod.outlook.com (2603:10b6:301:4f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Mon, 14 Sep 2020 21:44:20 +0000
Received: from MW3PR11MB4763.namprd11.prod.outlook.com ([fe80::8dbb:cee1:941a:7fe]) by MW3PR11MB4763.namprd11.prod.outlook.com ([fe80::8dbb:cee1:941a:7fe%4]) with mapi id 15.20.3370.019; Mon, 14 Sep 2020 21:44:20 +0000
From: "Brian Hartvigsen (bhartvig)" <bhartvig@cisco.com>
To: Geoff Huston <gih@apnic.net>, Paul Wouters <paul@nohats.ca>, Paul Hoffman <paul.hoffman@icann.org>
CC: "dprive@ietf.org" <dprive@ietf.org>
Thread-Topic: [dns-privacy] [Ext] Opportunistic encryption between recursive and authoritative servers
Thread-Index: AQHWiJmfptmgSLPJzkSoBi4Ghx0/86lkLvEAgAFW0gCAAsTagA==
Date: Mon, 14 Sep 2020 21:44:20 +0000
Message-ID: <361CEDFE-9C69-4CC6-A043-840B6233A601@cisco.com>
References: <5AB5385A-FE70-4FB0-810A-1EF0762094E2@icann.org> <8C8C42D7-EC2F-4374-A508-2BE3824B768D@nohats.ca> <47B5776C-3CCF-4085-8F2A-B917F2102549@apnic.net>
In-Reply-To: <47B5776C-3CCF-4085-8F2A-B917F2102549@apnic.net>
Accept-Language: en-US, es-MX
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.40.20081000
authentication-results: apnic.net; dkim=none (message not signed) header.d=none;apnic.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [171.68.244.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d14338b9-ee50-4c59-cc7f-08d858f7565e
x-ms-traffictypediagnostic: MWHPR1101MB2110:
x-microsoft-antispam-prvs: <MWHPR1101MB2110A19E207089547E5E4EF4D5230@MWHPR1101MB2110.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7Fi+Q7xo7mWjKqF++g/f8eWSFe4wSsofWATupO/u+hIclzm1pzUL6bArQD/KVD3y4rqxRVVC8PkDSnQbLXXVe5ZwkGn79nLQhOIDhfx86CXj2Cfq09O9XzgNg625Gbzfu8kC9uLLKRHh0CYEmW8v5Ufy3dHr7hDASIg9FeGIsUL5cvYa2tH/Ik0JVfEkxu9sojdh9SmUxMYTFA5yiNF3nM+CDHz5mirF4CU/bHJytCJW/QfzQVPuf49ToZAR632+rCxIizFvYDUyG55YvGJJ+VkCTb6xd6OZpAo5K81J7xioQkznUf1/eVTuMwASSUEZf7YIqhb821ihNxneaHH2Im/QiQC/I1gCilNomD7dOxFWl7bZ7W7MGPJh8j7lg5RBYjq3/Lts4owv1wa+/3cYmg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4763.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(39860400002)(396003)(136003)(366004)(346002)(71200400001)(76116006)(8936002)(36756003)(316002)(478600001)(2616005)(5660300002)(66556008)(33656002)(66446008)(2906002)(186003)(64756008)(66946007)(4326008)(26005)(66476007)(8676002)(110136005)(83380400001)(86362001)(66574015)(83080400001)(966005)(6506007)(6486002)(6512007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Aap9TcS4AXYjyWDLAQSpypJemQWScx2C4EJZxOFSsQsZjz/IblUIt/xXleqZC+36vMks/ufB6r5e0jkL2kVE1LY17C+HyNBnGEiOVDHZz2l9ImcAwOBDpH+li1fQ85+zRHfj5kkcfX92BhzlnAD2idKCNPtIL6Tpyqr2QICyGVudsvpwpDaQ+Qoa3bNLKwePq1u16sMTggMl6Zl5TXjOGXASFU5svy/PrjbiRLhlHpZv3WQQmExDvdmIHfoFSBPResyaYlEcAXbDSKTE0nguJHjoEZKm+l1gvlCxPNqEMh+vZ9Et3wxV5rfD2q4ZwtEO13OD4Y9biQRLyNHcfTqhUx9V2oH8GnuF85njs84E9N4s2D/mupYbw1J6nh/eMrw+osCcDHnqqpo8Z3vpJS2SSn0TCZpCYScdk6cSzrSGtPEQhAKOBU8l3VuZqEYHw6uij/0dIyx9J8s8FsXd9jwm9UYzp+w5uSwIGryDZgAwwsDAhm3dzi0q0kTzaBjfl1OG6etTIg0iYxhRgKvLL25FbR1D9/eEv6gkahkcSYY1hB6UmM33Amey0w6PNhuGCanvl5aWLQONGBAq/8ZAG266jm1wqYW46AW12xEQXeYL3bQU/PKl4fECF9r6Zo5uLGuHW4gBv0X4kPjyXgON42K3bg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <74D15E0EC8ABDE49972E0A6FEB72E3DE@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4763.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d14338b9-ee50-4c59-cc7f-08d858f7565e
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2020 21:44:20.1746 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rXznIHo3d3tCX9+AdhlB+ve+VOGruDhs9ieRB483diyyNDbbQ1BZUzbuvTrQ6pp5vnn/J3lLTlGlCD2vpAODwQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2110
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/nhnl2GoPPrYDFMJwjRexc1ikPA4>
Subject: Re: [dns-privacy] [Ext] Opportunistic encryption between recursive and authoritative servers
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2020 21:44:26 -0000

Point of clarification, all OpenDNS/Cisco Umbrella resolvers do DNSSEC validation and enforcement for all production traffic[1]. Silent validation started almost a year ago. Active enforcement (SERVFAIL on validation failure) has been happening since March 10th. If you are seeing something that indicates otherwise, please reach out.


-- Brian

[1] Somers presented on our then current DNSSEC story at DNS-OARC 32 in San Francisco - https://indico.dns-oarc.net/event/33/contributions/751/attachments/724/1228/20200201_DNSSEC_Recursive_Resolution_From_the_Ground_Up.pptx
 

On 9/12/20, 15:27, "dns-privacy on behalf of Geoff Huston" <dns-privacy-bounces@ietf.org on behalf of gih@apnic.net> wrote:

    Paul and Paul (and the WG),

    > 
    >> Primarily because that is only of value to resolvers that are validating, and that's the small minority of resolvers.
    > 

    Whats “a resolver”? Is Google’s DNS service one resolver or hundreds? Of Cloudflare’s 1.1.1.1 farm? What about Chinanet’s service where thousands of IP addresses all act in remarkably similar ways? Frankly, any statement about “the majority of” or “the minority of” resolvers is a pretty meaningless statement from such a perspective. Is my recursive resolver at home that answers queries for just me equal in any way to Google’s service which is used by one quarter of the Internet’s users? Yeah they are both resolvers, but thats about it.

    > 
    > Which of large resolver operators is not validating ?


    well we have a good idea of the answer to that question:

    Open DNS resolvers that do not perform DNSSEC validation:

    114dns (VERY large in China)
    dnspai (again, big in China)
    onedns
    opendns (some instances of Opendns’s cloud, but by no means the entirety)

    > Which of the stock opensource resolvers is not validating with a default configuration ? 

    I believe there are a few that require the local admin to enable it and the distro has it disabled by default.


    > 
    > Arguably the only ones left not validating are phones and we are busy giving them DoH and DoT to servers that do that for them.


    um, not really. In the US the ISP resolvers that don't validate include AT&T, Cellco, T-Mobile, UUNET, Charter,... It's probably easier to list the major ISPs in the US that do DNSSEC validate : Comcast. In Canada the ISPs resolver systems that don't include BACOM, Rogers, Shaw,…  Further afield, some of the extremely large ISP resolvers in India validate (Reliance Jio), but in China, not.


    > 
    > I think your argument does not hold.

    I find it hard to agree with either assertion about the prevalence of use of DNSSEC validation here.

    The argument that DNSSEC is just a minority corner case does not hold water these days - 25% of the world’s users pass their queries through DNSSEC validating resolvers and will not get an answer if the validation fails. A further 10% of users also use DNSSEC validation and then fail over to non-validating resolvers in the event of validation failure. 1/3 of the total user base of today’s Internet use DNS recursive resolvers that perform DNSSEC validation. Thats not a small minority. There is a lot of DNSSEC validation out there for users and a lot of large resolver systems serving these users.

    But 2/3 of users do not use DNSSEC validating resolvers. So it's by means the default case for the DNS.

    But DNSSEC validation continues an upward trend and given the standard lifetime of IETF work (2 years and 17 days on average for a draft these days) then the numbers for DNSSEC use will only grow. Accordingly, I have far more sympathy with Paul Wouter’s assertion that bringing in yet another mechanism of opportunistic encryption is one more straw-like adornment to the DNS camel (to use my own interpretation of Paul W’s comments) while a TLSA record could perform the same role, obviating the need for opportunistic encryption to authoritative servers.

    regards,

    Geoff

    _______________________________________________
    dns-privacy mailing list
    dns-privacy@ietf.org
    https://www.ietf.org/mailman/listinfo/dns-privacy