Re: [DNSOP] QNAME minimisation on the standards track?
Jonathan Reed <jreed@akamai.com> Fri, 20 July 2018 13:40 UTC
Return-Path: <jreed@akamai.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3668A13101E for <dnsop@ietfa.amsl.com>; Fri, 20 Jul 2018 06:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 uqOVAJ0QJA8X for <dnsop@ietfa.amsl.com>; Fri, 20 Jul 2018 06:40:14 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 64C971311B8 for <dnsop@ietf.org>; Fri, 20 Jul 2018 06:40:14 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6KDao40010954; Fri, 20 Jul 2018 14:40:12 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : in-reply-to : message-id : references : mime-version : content-type : content-id; s=jan2016.eng; bh=EPlifdwGcBdDnQjhyttcr+4buj1V+HvCQMiNdfSVbb4=; b=ETC0rXglXXBNFnVwM6KYQgblztx7a/DLBHZbNKyT9lqtrkS7AQTkBeMiF3o7hIl/2JP2 I9k0gHd1xBzq5ouhsqtxas45Smcbq/mHlO/BCrj9Rje9mJfq+hXmhpZN48cuGLUy3I6Z 6SC7xiqlfTgyOwl+IUKl1e9oKuJvlujw0LLECzpH9sGgB5UWAf0kFwCWZpo39/wQ/yM2 RnDWsyGCsNaOta71kVanbxovp1ZGAOt/PZBMSI1f7+VcnxI9CLl/50gFJY2z8WXuugr5 nfDXH/8DnXJywWFpuZa2RvFvUT1Le85xjg0XdLbAYvL/RCR6P+AkyS8/rXpV4w9iioSH jQ==
Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2kbeycrahw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Jul 2018 14:40:11 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6KDYYgx014560; Fri, 20 Jul 2018 09:40:11 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2k7cgwdbap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 20 Jul 2018 09:40:09 -0400
Received: from USMA1EX-CAS3.msg.corp.akamai.com (172.27.123.32) by usma1ex-dag3mb2.msg.corp.akamai.com (172.27.123.59) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 20 Jul 2018 09:40:07 -0400
Received: from bos-lpg69.kendall.corp.akamai.com (172.28.11.192) by USMA1EX-CAS3.msg.corp.akamai.com (172.27.123.32) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Fri, 20 Jul 2018 09:40:07 -0400
Date: Fri, 20 Jul 2018 09:40:07 -0400
From: Jonathan Reed <jreed@akamai.com>
X-X-Sender: jreed@bos-lpg69.kendall.corp.akamai.com
To: manu tman <chantr4@gmail.com>
CC: paul@nohats.ca, dnsop <dnsop@ietf.org>
In-Reply-To: <CAArYzr+g5a8txJYV5z7ora_Y54ys0fi3UOQBbgosxGUnYfdGcA@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1807181100320.17082@bos-lpg69.kendall.corp.akamai.com>
References: <20180717121406.GA6681@laperouse.bortzmeyer.org> <0E1026DD-2304-43FE-BEED-B9CE2981D9E3@gmail.com> <alpine.LRH.2.21.1807171724540.3719@bofh.nohats.ca> <CAArYzr+g5a8txJYV5z7ora_Y54ys0fi3UOQBbgosxGUnYfdGcA@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-448121252-1531928297=:17082"
Content-ID: <alpine.DEB.2.20.1807200940050.22913@bos-lpg69.kendall.corp.akamai.com>
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-20_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=565 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807200155
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-20_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=510 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807200155
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XIX16DCe2ln3ZnZai723v32ZIjE>
Subject: Re: [DNSOP] QNAME minimisation on the standards track?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jul 2018 13:40:21 -0000
On Tue, 17 Jul 2018, manu tman wrote: > I'd like to see this standardized too. > Side note: I would also be interested to get a return of experience from people operating qname minimization at scale, I suspect you're looking for feedback from recursive operators, but I'd like to share our experience as an authoritative operator. Supporting QNAME minimization as an authoritative implies correctly responding NOERROR to empty-non-terminals (ENTs) within the zone. RFC 4592 clarifies the interaction between wildcards and ENTs, however this poses a problem with customer-provided zone data. RFC 4592's behavior is not intuitive to most of our customers, and given that many other authoritative operators did not (and perhaps still don't) correctly handle interaction between wildcards and ENTs, we received significant customer pushback when we started correctly handling ENTs and wildcards. In short, as far as customers are concerned, '*' should always match "across" dots. _We_ all understand why it doesn't, but it's not intuitive to our customers, and it is no longer the case that the person managing a company's zone has an extensive background in DNS. (Nor, frankly, should it be the case). Here's a common example: Consider a SaaS/cloud provider that onboards customers through CNAMEs. For example, cloudco.biz would onboard example.com by creating "example.com.cloudco.biz" and CNAMEing it to some internal name. The SaaS provider also typically has a wildcard at/below the apex of their zone (*.cloudco.biz) to gracefully handle their customers who may put the CNAME in place before they have been fully provisioned. Such a zone, by definition, potentially has ENTs at every possible TLD. Thus, www.notyetprovisioned.com.clouco.biz will never match the wildcard at the apex, because of the ENT at com.cloudco.biz. The SaaS provider is now causing a significant outage for their in-the-process-of-onboarding customers, and the provider is rightly very unenthusiastic about copying that apex wildcard down to every TLD. The problem is further compounded with ccTLDs (www.example.co.uk.cloudco.biz creates two ENTs: one at uk, one at co.uk). This rapidly becomes an untenable solution for our customers, and they're likely to seek out another authoritative provider. I realize this is a somewhat a special case, but there were (still are?) many large authoritative DNS providers in this position, and our effort to support QNAME minimization pushed a large operational problem onto our customers. -Jon -- Jonathan Reed Senior Performance Engineer Akamai Technologies > the type of issues encountered, what are the ratios of such errors.... hint @marek :) > > Manu > > On Tue, Jul 17, 2018 at 2:35 PM Paul Wouters <paul@nohats.ca> wrote: > On Tue, 17 Jul 2018, tjw ietf wrote: > > > Subject: Re: [DNSOP] QNAME minimisation on the standards track? > > > > I’d like to see a more fleshed out operational considerations section. > > That would be good indeed. Especially with respect to broken DNS load > balancers. > > I have enabled it in Fedora from the start and did run into a few problem > domains, and some people turning it off. But that happened less than I > had expected. Red Hat did not yet enable this in RHEL7 but it is planned > to be enabled in RHEL8. > > But I do believe qname minimisation is an important privacy enhancing > technology that we should strongly promote as a standards track > document. > > Paul > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > >
- [DNSOP] QNAME minimisation on the standards track? Stephane Bortzmeyer
- Re: [DNSOP] QNAME minimisation on the standards t… Puneet Sood
- Re: [DNSOP] QNAME minimisation on the standards t… tjw ietf
- Re: [DNSOP] QNAME minimisation on the standards t… Marek Vavruša
- Re: [DNSOP] QNAME minimisation on the standards t… Paul Wouters
- Re: [DNSOP] QNAME minimisation on the standards t… manu tman
- Re: [DNSOP] QNAME minimisation on the standards t… Paul Hoffman
- Re: [DNSOP] QNAME minimisation on the standards t… Sara Dickinson
- Re: [DNSOP] QNAME minimisation on the standards t… Dan York
- Re: [DNSOP] QNAME minimisation on the standards t… Petr Špaček
- Re: [DNSOP] QNAME minimisation on the standards t… Jonathan Reed
- Re: [DNSOP] QNAME minimisation on the standards t… Tim Wicinski
- Re: [DNSOP] QNAME minimisation on the standards t… manu tman