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

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 17 Jul 2018 08:14:06 -0400

Greetings. With more resolvers implementing QNAME minimisation, and
even turning it on by default, we thought that this is a good time to
update RFC 7816 and make it a standard. In order to get things moving,
we have published a very early draft draft-bortzmeyer-rfc7816bis-00
that is mostly the original RFC but with a few questions and holes
added (see the text near the strings "TODO"). If folks in the WG is
interested, feel free to comment in the non-GitHub repo listed in the
draft, or here on the list.

---

From: Puneet Sood <[email-masked]>
Date: Tue, 17 Jul 2018 12:03:13 -0400

I have interest in seeing this standardized.
On Tue, Jul 17, 2018 at 8:25 AM Stephane Bortzmeyer <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: tjw ietf <[email-masked]>
Date: Tue, 17 Jul 2018 13:01:57 -0400

I’d like to see a more fleshed out operational considerations section.  

Tim
As chair 

From my high tech gadget

> On Jul 17, 2018, at 08:14, Stephane Bortzmeyer <[email-masked]> wrote:
>

---

From: Marek Vavruša <[email-masked]>
Date: Tue, 17 Jul 2018 11:54:00 -0700

I'd like to see this on the standards track as well. Cloudflare has
some operational experience with it (it's enabled by default on
1.1.1.1). It mostly works, but still has to be turned off on several
delegations that either don't respond to non-terminals, respond with
positive answer that's invalid (usually when there's an LB that only
handles final name, but gives out a referral to intermediate name), or
respond with nxdomain (this is the most common one and well known).

---

From: Paul Wouters <[email-masked]>
Date: Tue, 17 Jul 2018 17:35:06 -0400 (EDT)

On Tue, 17 Jul 2018, tjw ietf wrote:

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

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

---

From: manu tman <[email-masked]>
Date: Tue, 17 Jul 2018 22:33:23 -0700

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, the type of issues
encountered, what are the ratios of such errors.... hint @marek :)

Manu

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 18 Jul 2018 07:30:26 -0400

> encountered, what are the ratios of such errors.... hint @marek :)

Just to be clear to the WG: Stéphane and I would love to be adding 
operational experience with minimization to the draft. That's the main 
reason we didn't just ask for the document to be moved from Experimental 
to Standards Track in-place.

--Paul Hoffman

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 18 Jul 2018 09:46:05 -0400

> On 17 Jul 2018, at 17:35, Paul Wouters <[email-masked]> wrote:
> 

+1

Sara.

---

From: Dan York <[email-masked]>
Date: Wed, 18 Jul 2018 14:04:44 +0000

> On Jul 18, 2018, at 9:46 AM, Sara Dickinson <[email-masked]> wrote:
> 
<snip>
>> technology that we should strongly promote as a standards track

+1. I think this is a valuable tool in our privacy toolbox and should be standardized.

Dan

---

From: Petr Špaček <[email-masked]>
Date: Wed, 18 Jul 2018 18:02:46 +0200

On 18.7.2018 16:04, Dan York wrote:
> 
>> On Jul 18, 2018, at 9:46 AM, Sara Dickinson <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> On 17 Jul 2018, at 17:35, Paul Wouters <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>

+1, our Knot Resolver enables it by default for couple years already.

-- 
Petr Špaček  @  CZ.NIC

---

From: Jonathan Reed <[email-masked]>
Date: Fri, 20 Jul 2018 09:40:07 -0400

On Tue, 17 Jul 2018, manu tman wrote:

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

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 20 Jul 2018 10:33:41 -0400

Jonathan

That's *exactly* the type of operational issues that I am interesting in
documenting.

(That doesn't mean the other chairs or the working group feel the same way,
in fact they probably won't!

Tim

On Fri, Jul 20, 2018 at 9:40 AM, Jonathan Reed <
jreed=[email-masked]> wrote:

>> people operating qname minimization at scale,
>>
>
> 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.
>
> customers who may put the CNAME in place before they have been fully
> provisioned.
>

---

From: manu tman <[email-masked]>
Date: Fri, 20 Jul 2018 09:01:17 -0700

That's a great feedback Jonathan! Thanks

Manu