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
