<div><div dir="auto">Thanks for letting us know — not just that it would be fixed, but also some of the details.  </div><div dir="auto"><br></div><div dir="auto">It’s things like this which make DNS-OARC worthwhile. They also improve Akamai’s reputation - everyone has bugs, but acknowledging them, and explaining the fix and impact is (unfortunately) less common.</div><div dir="auto"><br></div><div dir="auto">W</div><div dir="auto"><br></div><div dir="auto">W</div><br><div class="gmail_quote"><div>On Wed, Oct 4, 2017 at 11:11 AM David C Lawrence <<a href="mailto:tale@akamai.com">tale@akamai.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday at the DNS-OARC meeting, Ralf Weber of Nominum gave a very<br>
interesting presentation on cache performance. His slides are here:<br>
<br>
<a href="https://indico.dns-oarc.net/event/27/session/5/contribution/5/material/slides/0.pdf" rel="noreferrer" target="_blank">https://indico.dns-oarc.net/event/27/session/5/contribution/5/material/slides/0.pdf</a><br>
<br>
One of his observations was that he was getting a surprisingly high<br>
number of cache misses for Akamai names.  He eventually tracked this<br>
down to uncacheable negative answers where our authorities had not<br>
included an SOA in the response.  This was certainly a surprising<br>
finding to me, and so I got up to the mic and acknowledged it was<br>
unintentional and that we would endeavour to fix it quickly.<br>
<br>
The fix was deployed on Monday afternoon.<br>
<br>
It turns out that this was a bug introduced with a software release<br>
that completed on 30 August.  It had not been present in previous<br>
releases.  One of the nameservers team members noticed the problem and<br>
had already fixed it for the next software release, due imminently,<br>
but hadn't made the leap as to the implications for resolver caches.<br>
<br>
The reason for the bug is buried in the finer points of the<br>
architecture of our nameserver, but can generally be described as the<br>
interactions of a particular configuration that was unfortunately not<br>
well-represented in developer testing but is very common in<br>
production.  We're working to remedy that testing gap.<br>
<br>
There is a dynamic configuration switch that could be flipped to bypass<br>
the bug and that was sent out on Monday.  We now return you to your<br>
regularly scheduled negative answers.<br>
<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
dns-operations mailing list<br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature">I don't think the execution is relevant when it was obviously a bad idea in the first place.<br>This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.<br>   ---maf</div>