That's a great feedback Jonathan! Thanks Manu
On Fri, Jul 20, 2018 at 6:40 AM Jonathan Reed <jr...@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 <p...@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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
