Re: [DNSOP] QNAME minimisation on the standards track?
That's a great feedback Jonathan! Thanks Manu On Fri, Jul 20, 2018 at 6:40 AM Jonathan Reed 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 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
Re: [DNSOP] QNAME minimisation on the standards track?
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 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
Re: [DNSOP] QNAME minimisation on the standards track?
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 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
Re: [DNSOP] QNAME minimisation on the standards track?
On 18.7.2018 16:04, Dan York wrote: > >> On Jul 18, 2018, at 9:46 AM, Sara Dickinson > <mailto:s...@sinodun.com>> wrote: >> >>> On 17 Jul 2018, at 17:35, Paul Wouters >> <mailto: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. > >>> >>> But I do believe qname minimisation is an important privacy enhancing >>> technology that we should strongly promote as a standards track >>> document. >> >> +1 >> >> Sara. > > +1. I think this is a valuable tool in our privacy toolbox and should be > standardized. > > Dan +1, our Knot Resolver enables it by default for couple years already. -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QNAME minimisation on the standards track?
> On Jul 18, 2018, at 9:46 AM, Sara Dickinson wrote: > >> On 17 Jul 2018, at 17:35, Paul Wouters 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. >> >> But I do believe qname minimisation is an important privacy enhancing >> technology that we should strongly promote as a standards track >> document. > > +1 > > Sara. +1. I think this is a valuable tool in our privacy toolbox and should be standardized. Dan smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QNAME minimisation on the standards track?
> On 17 Jul 2018, at 17:35, Paul Wouters 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. +1 Sara. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QNAME minimisation on the standards track?
On 18 Jul 2018, at 1:33, 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, the type of issues 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QNAME minimisation on the standards track?
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 On Tue, Jul 17, 2018 at 2:35 PM Paul Wouters 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
Re: [DNSOP] QNAME minimisation on the standards track?
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
Re: [DNSOP] QNAME minimisation on the standards track?
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). On Tue, Jul 17, 2018 at 10:01 AM, tjw ietf wrote: > 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 wrote: >> >> 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. >> >> >> >> ___ >> 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
Re: [DNSOP] QNAME minimisation on the standards track?
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 wrote: > > 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. > > > > ___ > 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] QNAME minimisation on the standards track?
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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
