<div dir="ltr"><div dir="ltr"><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 6, 2021 at 10:45 AM Michael Thomas <<a href="mailto:mike@mtcc.com">mike@mtcc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So if I understand their post correctly, their DNS servers have the <br>
ability to withdraw routes if they determine are sub-optimal (fsvo). I <br>
can certainly understand for the DNS servers to not give answers they <br>
think are unreachable but there is always the problem that they may be <br>
partitioned and not the routes themselves. At a minimum, I would think <br>
they'd need some consensus protocol that says that it's broken across <br>
multiple servers.<br>
<br>
But I just don't understand why this is a good idea at all. Network <br>
topology is not DNS's bailiwick so using it as a trigger to withdraw <br>
routes seems really strange and fraught with unintended consequences. <br>
Why is it a good idea to withdraw the route if it doesn't seem reachable <br>
from the DNS server? Give answers that are reachable, sure, but to <br>
actually make a topology decision? Yikes. And what happens to the cached <br>
answers that still point to the supposedly dead route? They're going to <br>
fail until the TTL expires anyway so why is it preferable withdraw the <br>
route too?<br>
<br>
My guess is that their post while more clear that most doesn't go into <br>
enough detail, but is it me or does it seem like this is a really weird <br>
thing to do?<br>
<br>
Mike<br></blockquote><div><br></div><div><br></div><div>Hi Mike,</div><div><br></div><div>You're kinda thinking about this from the wrong angle.</div><div><br></div><div>It's not that the route is withdrawn if doesn't seem reachable </div><div>from the DNS server.</div><div><br></div><div>It's that your DNS server is geolocating requests to the nearest </div><div>content delivery cluster, where the CDN cluster is likely fetching </div><div>content from a core datacenter elsewhere.  You don't want that </div><div>remote/edge CDN node to give back A records for a CDN node </div><div>that is isolated from the rest of the network and can't reach the </div><div>datacenter to fetch the necessary content; otherwise, you'll have </div><div>clients that reach the page, can load the static elements on the </div><div>page, but all the dynamic elements hang, waiting for a fetch to </div><div>complete from the origin which won't ever complete.  Not a very </div><div>good end user experience.</div><div><br></div><div>So, the idea is that if the edge CDN node loses connectivity to </div><div>the core datacenters, the DNS servers should stop answering </div><div>queries for A records with the local CDN node's address, and </div><div>let a different site respond back to the client's DNS request.</div><div>In particular, you really don't want the client to even send the </div><div>request to the edge CDN node that's been isolated, you want </div><div>to allow anycast to find the next-best edge site; so, once the </div><div>DNS servers fail the "can-I-reach-my-datacenter" health check, </div><div>they stop announcing the Anycast service address to the local </div><div>routers; that way, they drop out of the Anycast pool, and normal </div><div>Internet routing will ensure the client DNS requests are now sent </div><div>to the next-nearest edge CDN cluster for resolution and retrieving </div><div>data.</div><div><br></div><div>This works fine for ensuring that one or two edge sites that get </div><div>isolated due to fiber cuts don't end up pulling client requests into </div><div>them, and subsequently leaving the users hanging, waiting for </div><div>data that will never arrive.</div><div><br></div><div>However, it fails big-time if *all* sites fail their "can-I-reach-the-datacenter" </div><div>check simultaneously.  When I was involved in the decision making </div><div>on a design like this, a choice was made to have a set of "really core" </div><div>sites in the middle of the network always announce the anycast prefixes, </div><div>as a fallback, so even if the routing wasn't optimal to reach them, the </div><div>users would still get *some* level of reply back. </div><div><br></div><div>In this situation, that would have ensured that at least some DNS </div><div>servers were reachable; but it wouldn't have fixed the "oh crap we </div><div>pushed 'no router bgp' out to all the routers at the same time" type </div><div>problem.  But that isn't really the core of your question, so we'll </div><div>just quietly push that aside for now.   ^_^;</div><div><br></div><div>Point being--it's useful and normal for edge sites that may become </div><div>isolated from the rest of the network to be configured to stop announcing </div><div>the Anycast service address for DNS out to local peers and transit </div><div>providers at that site during the period in which they are isolated, to </div><div>prevent users from being directed to CDN servers which can't fetch </div><div>content from the origin servers in the datacenter.  It's just generally </div><div>assumed that not every site will become "isolated" at the same time </div><div>like that.   :)</div><div><br></div><div>I hope this helps clear up the confusion.</div><div><br></div><div>Thanks!</div><div><br></div><div>Matt</div><div><br></div></div></div>