Re: [DNSOP] QNAME minimisation on the standards track?

manu tman <chantr4@gmail.com> Fri, 20 July 2018 16:01 UTC

Return-Path: <chantr4@gmail.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 13546130FF4 for <dnsop@ietfa.amsl.com>; Fri, 20 Jul 2018 09:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pDgB4lENjLJk for <dnsop@ietfa.amsl.com>; Fri, 20 Jul 2018 09:01:29 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F01130FDB for <dnsop@ietf.org>; Fri, 20 Jul 2018 09:01:29 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id s7-v6so15322872itb.4 for <dnsop@ietf.org>; Fri, 20 Jul 2018 09:01:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wKmAtA2fTGYx27EZ918RUGNV3IdbKqkFthR1VRfiHWg=; b=eM463VCEXvIvLOepPLfaeP/o2C/G1KLUAkU1It9O9hwAcUaZeD9rfgIOiDFa/AHTwV BDT3qmXcqEoZcFcIfa+Au3blaaPrXSYr1iijclA1Qvugx9X8sFG0gdgxgDaYYiMXhTUW UPQY7Zv9tCpiR7566HG7ybhzQWfY45tYHftoRohi/hZpQUO2g1lwrSLPpOy8hCDzuEMm 7gVoqgl+wXJHOcNkdU5E662dmve09KdrCf3DyeGmeEvg4k3MBQYc0H4T82BqqztfyC4f EmHDs609hWNaGBZg0cvi6LLAJJ8ASfdaldgKKpnj/98egpCcdW20IvS9W57kv26iRxKG IcQQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wKmAtA2fTGYx27EZ918RUGNV3IdbKqkFthR1VRfiHWg=; b=cs9g28JN4r8rZkYWv9H9PyGU7RhIyAunH019FDt25uzwFKhFcSgl4ZnVrC9vpW/r5n b1hX5GB0/ptqfKhNFwr/+XXpnE+O2uDzxb7nK74GIAZtw97KYuCRVut46OdrqBT7uhtK 7mYiAH79+m++vvEkOeQxfAauRX2HkX7Le063Oel+yUSQ3bOnzReCjPG4La0buLeEIw3I pFuit3BLbbcvMWBT7aS2PKdp1EQBeK80FGVbJXKvoZBAzl+uhDBrT8NmOUUt/7jeP7rU SDxg79OCGqwgKM0Cf5HCje6/aHlu2hoKnxa6o8OCAsJt5l/L1Ospk0hjz8H8n51Pc6D3 adQA==
X-Gm-Message-State: AOUpUlEJ4FZPCsB6pkZ3uhnGDPgIxLj+cNUBTsYdEzaUtiikfQkb+Que wgpu53hJrAm5SMRkxlJAm0Kbsw1PBDROMlZXUFE=
X-Google-Smtp-Source: AAOMgpcMpzAs12qPvJm6KcXsTEN+ChHpb+5C1GNPxGI4IqAdixRt8ml19ZjpbNmQ5MG0KkYf3hlqPNV0bijgfx+q56g=
X-Received: by 2002:a24:4112:: with SMTP id x18-v6mr2326880ita.83.1532102488634; Fri, 20 Jul 2018 09:01:28 -0700 (PDT)
MIME-Version: 1.0
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> <alpine.DEB.2.20.1807181100320.17082@bos-lpg69.kendall.corp.akamai.com>
In-Reply-To: <alpine.DEB.2.20.1807181100320.17082@bos-lpg69.kendall.corp.akamai.com>
From: manu tman <chantr4@gmail.com>
Date: Fri, 20 Jul 2018 09:01:17 -0700
Message-ID: <CAArYzr+tY4h1aZ1o1U85wvC=dQU2mZqTjiPj7i0ELcOdT6s6zw@mail.gmail.com>
To: jreed@akamai.com
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000098392f057170681f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GlfYDBtVWCLreFP5BfUbH5iZJj4>
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 16:01:32 -0000

That's a great feedback Jonathan! Thanks

Manu

On Fri, Jul 20, 2018 at 6:40 AM Jonathan Reed <jreed@akamai.com> wrote:

>
> 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
> >
> >
> >