[dns-operations] Akamai now works with ENT (Empty Non-Terminals)?
shuque at gmail.com
Sun Apr 14 00:49:29 UTC 2019
On Sat, Apr 13, 2019 at 7:46 AM Reed, Jon <jreed at akamai.com> wrote:
> Our CDN zones have supported ENTs since July 2018. I was heavily
> involved with this, and am happy to answer follow-up questions either
> on-list or off-list.
I'm glad to hear this.
There were a number of challenging problems, specifically around empty
> non-terminals and their interaction with wildcards described in RFC 4592.
> The behavior is completely non-intuitive to anyone who isn't a DNS expert.
> I wrote a fairly detailed response about this on the dnsop list during
> IETF 102, in response to a thread started by Stéphane:
I do remember hearing from Tale about operational problems that were
preventing Akamai from deploying their Empty Non-Terminal response fix, but
I must admit I never got around to learning the details. Thanks for the
detailed explanation you provided at this link. (I'm on that list, but
somehow your note evaded my notice.)
Now that you've deployed the fix, are you able to share how you addressed
the customer expectation problem that you describe? e.g. Did you advise
customers not to deploy CNAME records before they are fully provisioned?
Did you deploy special case code in your nameservers for these services to
match wildcards above or parallel to the ENTs, while providing NODATA
responses to the ENTs? Or something else?
> At the time, many other large cloud providers also exhibited incorrect
> behavior around wildcards and empty non-terminals, but I think Akamai was
> called out specifically at OARC 27 or 28 with this GIF:
It was being discussed much earlier actually. I gave this presentation at
the Spring 2015 OARC workshop, where I discussed this problem in the
context of a qname minimization survey:
At that time, Akamai and Cloudflare were the main problematic services in a
survey of the Alexa top 1000 sites. I notified both of them well before my
talk, and Cloudflare had already fixed their ENT response behavior by the
time of the talk. There were several Chinese CDN providers on the list too
- I managed to contact a couple of them, and they informed me they were
working on fixes, but I didn't follow up and check on their status.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dns-operations