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=40akamai....@dmarc.ietf.org> 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 > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
