Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

Andrew Campling <andrew.campling@419.consulting> Wed, 27 November 2019 22:09 UTC

Return-Path: <andrew.campling@419.consulting>
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 165A8120AD7 for <dns-privacy@ietfa.amsl.com>; Wed, 27 Nov 2019 14:09:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 ctig_6XCykb5 for <dns-privacy@ietfa.amsl.com>; Wed, 27 Nov 2019 14:09:04 -0800 (PST)
Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100049.outbound.protection.outlook.com [40.107.10.49]) (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 CAFA0120ACF for <dns-privacy@ietf.org>; Wed, 27 Nov 2019 14:09:03 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EuCbBTtJWoVA/8gpfzsThUDv0xnnFe/WZsSvJS0I+iHjcv7kq3mqrt87sCt3ZX6OY+zHmYINehyRsPfT4UM8XnFDzp6kHcJHZ+gEkiv3poR5t68Tba/zmc95c83g5fXhQE57ghpdUNLze885rU+2ClfkhYRf9Ox2uCpblvem6BGyGPyotiipe4dE6WMGQugg7B4rUQg6NK0aBSyTDAgL26947pUBP5d1FuajllqGHnxThlLuEXRo+oQIK6iARSbKm4xa/8RmScJdAFt1Rh87a2saVzUHGtoco7jUBULrS6eZFd/1+z/PsHl1o8FZW1M2fP0As6qUDhm54fK5PoCfJA==
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=LeW546bBKDPvuTg8oOKBHvVPQBv3skRAutl6CtGTP9U=; b=ZoSjg0ylvL4bfHIWZrNNcGCMyzSFRgGy/spd9838vl+P2n3UAEzfcDykShq+neUWVg0enhl7eR/zm8DETPOXj7oyRGEEIbm5aEiBbMXsDofFK+CZJR8+ytxsQ+7o/km5MMcW4gFVzLrf4sCIkP/jMxaBUitvwkiGpR1+uew5JhK/2z+YwD71eL0gcspO1rHQpPot6R9urgF4ByDHoT6beqXxYPd0YHAK/+13BFnxmVlIHClmWqnXLUla/K6nAULinsKojlvnqqDjhiIetBGJVaaBSoT2EpNcPh62ocaeTS0VslbUQwKwp9ldpRR0hFuhAcNH8eG6+IWOxlhpQGtHzw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LeW546bBKDPvuTg8oOKBHvVPQBv3skRAutl6CtGTP9U=; b=UnGCqg/rlGnEI7e0qrmN0IXjX9fUi1dEOF7cjf742SRVgUUA2iInbsZ8N9XC+WcqWnB9B83F60tlZsdbnL2MIjEmOF01QY6rBZtQ7Yx8Ve0mfWG/NzVOJRuVRZ+6Khk8qG2dMUA8Nau3miANX6DEuTbmpJJYkfkLx1/sLAqXzAs=
Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB1293.GBRP265.PROD.OUTLOOK.COM (20.176.139.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.21; Wed, 27 Nov 2019 22:09:01 +0000
Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712%7]) with mapi id 15.20.2474.023; Wed, 27 Nov 2019 22:09:01 +0000
From: Andrew Campling <andrew.campling@419.consulting>
To: "Livingood, Jason" <Jason_Livingood@comcast.com>, Stephane Bortzmeyer <bortzmeyer@nic.fr>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [dns-privacy] Trying to understand DNS resolver 'discovery'
Thread-Index: AQHVpTyazLhOM+aXW0mYfu60KSTtvKefkzlg
Date: Wed, 27 Nov 2019 22:09:00 +0000
Message-ID: <LO2P265MB05736FAB2D38226EB21D9C72C2440@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
References: <CAMm+Lwig+90Riqav6BT6D-0n4pZJFgAr3p996Q+qXJSPt0kqBQ@mail.gmail.com> <20191126180441.GA4452@sources.org> <CY4PR1601MB125470ADE243F60FB710E8C7EA440@CY4PR1601MB1254.namprd16.prod.outlook.com> <20191127142842.GA18601@nic.fr> <716ED073-F71D-412C-A54B-D060DDC6F469@cable.comcast.com>
In-Reply-To: <716ED073-F71D-412C-A54B-D060DDC6F469@cable.comcast.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting;
x-originating-ip: [213.205.194.107]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ceb59488-cb90-48f4-9267-08d77386686a
x-ms-traffictypediagnostic: LO2P265MB1293:
x-microsoft-antispam-prvs: <LO2P265MB12932AD4B6E0FD4C58AB3519C2440@LO2P265MB1293.GBRP265.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 023495660C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39830400003)(396003)(136003)(346002)(189003)(199004)(13464003)(8936002)(66066001)(86362001)(71200400001)(76116006)(186003)(52536014)(256004)(229853002)(8676002)(81156014)(44832011)(6116002)(14444005)(102836004)(2501003)(5660300002)(99286004)(6246003)(81166006)(30864003)(53546011)(66446008)(66946007)(25786009)(66556008)(66476007)(9686003)(966005)(64756008)(6506007)(26005)(33656002)(74316002)(6436002)(316002)(6306002)(7736002)(55016002)(14454004)(11346002)(110136005)(71190400001)(446003)(508600001)(76176011)(66574012)(3846002)(305945005)(7696005)(2906002)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB1293; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hVC1+9WQMHtQZfuwfgUznbmPfKKLBb5dNI5Ts6vdd6RwqaxMUpbZaSZiqQl9s4Vrsp4dHyv4O88r0Sc7wA4bi5r9HhVjZIxjJAKSFfEaAyps4hK4pEjwTyW6xzV1BoqMdf/cGqAxZoOdpu4rgFndS/uXI0VZ52a5+ynWy0A0zSurGhCTg2upOSXaS8FaQB1/TgRWUQpQYwNShoLj4vxCRSH5wdbxkPC8UiGbTFZ+CTLv7cWrGFo7MY6lrJrsJ4ghhqv+NkNwOWyCi2Wod++BfDTDHUPgzOXmvAzlnX261FMQJ33EJbrski2+ZcN0oTWZSkkoA5nCbqCrYevYUR7OwYcu9nq84f/Q6CIx2opdx3KKu6B57cTX8qhdqlky/RHPJaY5RJT+QP0MI7jsVRA1JHayxzyc8w6wFAzpq00a6PyF8TD4RfWmlIaabUhRjMyY
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_LO2P265MB05736FAB2D38226EB21D9C72C2440LO2P265MB0573GBRP_"
MIME-Version: 1.0
X-OriginatorOrg: 419.consulting
X-MS-Exchange-CrossTenant-Network-Message-Id: ceb59488-cb90-48f4-9267-08d77386686a
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2019 22:09:00.9142 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: C6xzUMerqzSHjuIegkyUGrsqWkfUsTpi8GeNC0ryQ5shxn8bzifH1BRmDLtEKk4TcpRyNKGFvMET9Rz8vrEODC78WS8p5Fmi5Ybh+9frDdo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1293
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/3T9dNuoPJ-ieyGqimk4O5UdVJJ4>
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
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: Wed, 27 Nov 2019 22:09:06 -0000

+1 to Jason's comment - suggesting all DNS modification is bad indicates a misunderstanding of some real-world use cases.

Andrew

-----Original Message-----
From: Livingood, Jason <Jason_Livingood@comcast.com>
Sent: 27 November 2019 16:06
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>; dns-privacy@ietf.org
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

On 11/27/19, 9:29 AM, "dns-privacy on behalf of Stephane Bortzmeyer" <dns-privacy-bounces@ietf.org on behalf of bortzmeyer@nic.fr<mailto:dns-privacy-bounces@ietf.org%20on%20behalf%20of%20bortzmeyer@nic.fr>> wrote:

>    For instance, if your access provider has a lying resolver

I just wanted to take a moment to note that choosing to use the term 'lying' when describing resolver behavior is unnecessarily negative and seems designed to be intentionally divisive. This does not IMO contribute to a productive discussion and exchange of views at the IETF.

As has been long demonstrated here and in DNSOP, not all DNS modification can be considered 'lying' - given that lying obviously implies it is a negative thing that is counter to user preferences. For example, an opt-in parental control service that modifies responses is not a negative use case from the perspective of that user/parent. Similarly, a DNS modification in an enterprise that blocks malware C2 FQDNs is also from the enterprise's perspective a good thing.

It seems a better approach is to simply use a neutral term and call this DNS modification. Whether that is good or bad will depend on the particular use case or situation or other factors.

Thanks
Jason