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

[Tim Wicinski <[e-mail]>]

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=[e-mail]> 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 <[e-mail]> 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
>>       [e-mail]
>>       https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>