<div dir="auto"><div>Hi, </div><div dir="auto"><br></div><div dir="auto">correct, no actual NS records were changed. This was a wrong assumption on my part.</div><div dir="auto"><br></div><div dir="auto">The withdrawal of unreachable prefixes is common practice for any anycast service. </div><div dir="auto"><br></div><div dir="auto">In terms of solution, you could use 3rd party for some of your aDNS infrastructure IPs. You would then also need to have reachability of your DCs via 3rd party IP space or host your services in 3rd party infrastructure. I assume FB looked at this option and saw more benefits in being in total control of their infrastructure...  trust vs benefit....</div><div dir="auto"><br></div><div dir="auto">They could consider at least having some OOB reachability via an independent path, so to at least get into their boxes.</div><div dir="auto"><br></div><div dir="auto">What I still can't wrap my head around is that all datacenters globally stopped being reachable at once. I assume each DC has each own dedicated IP space. So if a script would remove advertisements of IP prefix of DC1 that aDNs that uses DC1 would remove it's Anycast prefix announcement, but shouldn't DC2 still be reachable? Perhaps therein lies the solution, limit your automation tools to one DC .... </div><div dir="auto"><br></div><div dir="auto">BR,</div><div dir="auto">Markus</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, 8 Oct 2021, 1:50 pm Daniel Shaw, <<a href="mailto:dshaw78@gmail.com" rel="noreferrer noreferrer" target="_blank">dshaw78@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
On Thu, 7 Oct 2021 at 10:35, Markus Akena Wipfler<br>
<<a href="mailto:markus.wipfler@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">markus.wipfler@gmail.com</a>> wrote:<br>
><br>
> All good and well but no mention of disappearance of the actual DNS records on their authoritative DNSes :) during that period. I don't think it's per design, eg remove DNS record if prefix X is not seen in routing table.<br>
><br>
<br>
I very much doubt any DNS *records* where changed anywhere. I am not<br>
sure why you think that.<br>
<br>
FB themselves say (ref<br>
<a href="https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/</a>)<br>
 that:<br>
<br>
" To ensure reliable operation, our DNS servers disable those BGP<br>
advertisements if they themselves can not speak to our data centers,<br>
since this is an indication of an unhealthy network connection. In the<br>
recent outage the entire backbone was removed from operation,  making<br>
these locations declare themselves unhealthy and withdraw those BGP<br>
advertisements. The end result was that our DNS servers became<br>
unreachable even though they were still operational. "<br>
<br>
This is matches with reports from folks who run DNS resolvers, which<br>
where giving back SERVFAIL - which is consistent with when the<br>
recursive resolver cannot talk to the upstream authoritative server at<br>
all.<br>
<br>
In other words, FB probably has anycast auth DNS systems in many<br>
distributed PoPs/locations.<br>
<br>
In each location, the systems monitor their own control-plane<br>
connections (FB's backbone). When that is down (and thus the PoP<br>
cannot get updates xfr in, cannot send logs back, etc.) then the<br>
systems withdraw the data-plane/anycast IPs so that traffic goes<br>
elsewhere.<br>
<br>
This is actually a great design for any partial outage. Any remote<br>
location that FB looses control of, would take itself offline from<br>
serving (soon to be stale) data. Anycast would ensure than traffic is<br>
sent to alternate locations.<br>
<br>
They clearly never planned for *ALL* locations to lose connection to<br>
home-base *at the same time*. Oops.<br>
<br>
-- Daniel<br>
</blockquote></div></div></div>