DNS pulling BGP routes?

Thu Oct 7 14:12:42 UTC 2021

>
> But, the reality is that it is impossible to correctly
> recognize server is unavailable or to correctly withdraw
> routes only when server is unavailable.
>

Not true at all.

On Thu, Oct 7, 2021 at 9:50 AM Masataka Ohta <
mohta at necom830.hpcl.titech.ac.jp> wrote:

> William Herrin wrote:
>
> >>> This is quite common to tie an underlying service announcement to BGP
> >>> announcements in an Anycast or similar environment.
> >>
> >> Yes, that is a commonly seen mistake with anycast.
> >
> > You don't know what you're talking about.
>
> I do but you don't.
>
> > If your anycast node stops
> > receiving updated data and you can't reach any of the other nodes to
> > check whether they're online, 99 times out of 100 this means a local
> > failure of some sort.
>
> Yes. In case of DNS, if expiration period of a zone is passed
> without successful check of the current most zone version,
> unicast or anycast name servers stop responding requests for
> the zone.
>
> But, it has nothing specifically to do with anycast. As there
> are other name servers with different IP addresses, there is
> no reason to withdraw routes. So?
>
> > You withdraw the node's announcement so that you
> > don't serve bad data to the end user.
>
> That will only introduce new failure modes of mismatches between
> server availability and server reachability and is a bad idea.
>
> > That's what happened here -
>
> Yes, facebook did wrong thing to actively withdraw routes.
>
> > Simply
> > turning themselves off, instead of withdrawing the routes, would
> > result in suboptimal performance.
>
> This time, facebook is saying that they could not reach their
> name servers even though the servers were perfectly working.
>
> How much performance, do you think, facebook enjoyed? A lot
> less than "suboptimal", I'm afraid.
>
>  > And 99 times out of 100, not doing
>  > one or the other would cause rather than prevent an outage.
>
> That is a commonly seen misconception wrongly assuming that
> server routes were withdrawn if and only if the server is
> unavailable.
>
> But, the reality is that it is impossible to correctly
> recognize server is unavailable or to correctly withdraw
> routes only when server is unavailable.
>
>                                                 Masataka Ohta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20211007/b85a21ed/attachment.html>