IETF Logo Mail Archive

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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Thu, 28 November 2019 11:05 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.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 10A7A120805 for <dns-privacy@ietfa.amsl.com>; Thu, 28 Nov 2019 03:05:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=mcafee.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 sQo717h9URUy for <dns-privacy@ietfa.amsl.com>; Thu, 28 Nov 2019 03:05:17 -0800 (PST)
Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FF71207FF for <dns-privacy@ietf.org>; Thu, 28 Nov 2019 03:05:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1574939116; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9euynuHBppf3qbRxSp9wtB5coj6+/sX+cI6gNvwtx3g=; b=MkZhbU9t8BpgIplLRZ7gh/4/BKyUe8X7UC0P/Fc/I8HsCV77tknYXFPTM+SMhKBNUZ+oNZ ozFHjro5K2JeONSjc3ptixvIAKSK9z4TbPFMHQ2Pn7VMwR/3oFjcjawXbgqaC8aX4UpzBx dkWyv9m53dcfWs/8QAA2neAl4LcAFNA=
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05lp2057.outbound.protection.outlook.com [104.47.48.57]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-336-ZwxAN_VVNiSVmIwuwD68Dw-1; Thu, 28 Nov 2019 06:05:14 -0500
Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1351.namprd16.prod.outlook.com (10.172.118.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.20; Thu, 28 Nov 2019 11:05:11 +0000
Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::4aa:ad9b:390a:f7af]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::4aa:ad9b:390a:f7af%12]) with mapi id 15.20.2474.023; Thu, 28 Nov 2019 11:05:11 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Andrew Campling <andrew.campling@419.consulting>, "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: AQHVpH/sjJ4BY7ksP0eWka61gH491qedvvOAgAD5mmCAAFxiAIAAGyEAgABlegCAANbCEA==
Date: Thu, 28 Nov 2019 11:05:11 +0000
Message-ID: <CY4PR1601MB1254A759EC4EA55D3B11603EEA470@CY4PR1601MB1254.namprd16.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> <LO2P265MB05736FAB2D38226EB21D9C72C2440@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
In-Reply-To: <LO2P265MB05736FAB2D38226EB21D9C72C2440@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.4.0.45
dlp-reaction: no-action
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c293e556-ad04-4811-8bc9-08d773f2d6d4
x-ms-traffictypediagnostic: CY4PR1601MB1351:
x-microsoft-antispam-prvs: <CY4PR1601MB135169D6EFB83C9AE4544AE1EA470@CY4PR1601MB1351.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0235CBE7D0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(39860400002)(346002)(136003)(396003)(32952001)(189003)(199004)(13464003)(52536014)(110136005)(81166006)(99286004)(66066001)(229853002)(81156014)(8936002)(8676002)(6436002)(186003)(53546011)(6506007)(71200400001)(71190400001)(5024004)(256004)(76176011)(14444005)(7696005)(11346002)(102836004)(446003)(33656002)(26005)(7736002)(6246003)(5660300002)(3846002)(6116002)(790700001)(236005)(2906002)(54896002)(74316002)(9686003)(6306002)(55016002)(316002)(2501003)(606006)(25786009)(86362001)(80792005)(66574012)(66476007)(76116006)(66946007)(966005)(478600001)(14454004)(66556008)(64756008)(66446008)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1351; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Hs1Oe6qWB8+iTbmiY/kpPQXUmwEFKIDP7xKZhosQjF7qOfLkSUV0vCMaoO0LFC5P4O2bqUOU1oUhvVvZPZHZkKn6ihGEvM49wzrUFKm7afSc6nLfRgnq8QF2kD38nEorC/ibAaRHQTwcFmxiSUbFnCsSSuk2becDQtanjylzwiALJfeuqdKnbCenOZ2U47vBEY+HwtEDNNJUZw2KWGAJJzkaiT4iLCCYrtNp7ZbCbUCxxP7ia5BY/8ERWGTHPNmDKH8X7AL8GNkoFRJxgYmsaLlnTCpdImQ/Mui4czYSL/qpSAPJcfAaz1OTNfR4rGyfaB/DUnsdaVEC/69sFgsC3nGHRwJdWNcAlEfBrKOar4L2jk1liMbki79eY1gl950/dpgQFg8j8zAMCQrfn1IsOUkFQ0QbM4I7VkAmBlCOzie7Rn5ujx1/9PbBHoJGfYs2vdsSxqX5ae+60/xIgaiYaPHIT/ikZkk9Zt+uZ86Ip+y7tpWFvLJCAoUxSOlirHZl
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: mcafee.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c293e556-ad04-4811-8bc9-08d773f2d6d4
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2019 11:05:11.8718 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 02jpf+LUo0hzNrx/9YB5TURfcnN+Gvi3D/l5hY+x5RGeXqLJP0XT8a8iRQsjoxTcuiiPUpZRmiWNnH8Co5SciLnmiEbRcjkliQHl04DxyB/woyWJmJGkf35dSKNLdHJA
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1351
X-MC-Unique: ZwxAN_VVNiSVmIwuwD68Dw-1
X-Mimecast-Spam-Score: 0
Content-Type: multipart/alternative; boundary="_000_CY4PR1601MB1254A759EC4EA55D3B11603EEA470CY4PR1601MB1254_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/pAWd920gRhh29uexPkPyY1vhEZs>
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: Thu, 28 Nov 2019 11:05:20 -0000

In addition, with the extended error codes defined in https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-08, client would know the reason for blocking access to a domain, solves the user experience problem and, DoT/DoH ensures the error response is not spoofed.

-Tiru

From: dns-privacy <dns-privacy-bounces@ietf.org> On Behalf Of Andrew Campling
Sent: Thursday, November 28, 2019 3:39 AM
To: Livingood, Jason <Jason_Livingood@comcast.com>; Stephane Bortzmeyer <bortzmeyer@nic.fr>; dns-privacy@ietf.org
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
+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<mailto:Jason_Livingood@comcast.com>>
Sent: 27 November 2019 16:06
To: Stephane Bortzmeyer <bortzmeyer@nic.fr<mailto:bortzmeyer@nic.fr>>; dns-privacy@ietf.org<mailto: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

v2.23.0 | Report a Bug | By Email