Some providers employ BGP anycast for their NS servers.

As a user, when doing a traceroute, many may show an identical location for both servers, for a given client.

When he.net used to anycast their DNS from different locations for a client in Europe, and one of their POPs went bust for a few hours, the ns server from that pop was unavailable for a number of minutes, prior to being taken over by another POP.

Basically, doesn't it take a certain number of seconds (or even minutes?) in BGP for the takeover to take place? Does it mean that if a provider is always routing all NS to a single location, then at any time, such setup would be completely cut-off from certain clients for some number of seconds should a certain POP go bust?

  • Besides what @rnxrx is telling you, understand that trying to use traceroute on the Internet is a fool's game. Many ISPs will reroute traceroute and ICMP in order to hide their internal network structures. It is a useful tool on your own network, where you know what to expect, but it can be completely misleading on the Internet. ISPs can reroute traceroute to normally use the backup path, and you would never see it change in the event of a failure that takes all traffic to the backup path.
    – Ron Maupin
    Jan 18 '17 at 0:03
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 10 '17 at 1:32
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 15 '17 at 18:57

It's hard to know. The issue is that the anycast route needs to be provisioned in such a way as to not get lost behind a summary route or otherwise held up such that a retraction is actually seen.

The other issue is how the carrier has linked the health of the service to the route advertisement. So - for example - if the /24 where the DNS server lives continues to be advertised whether the server is live or not (hopefully this isn't the case) then all manner of failures can occur without even an attempt at restoration.

IMO the ideal design should be advertising the route conditional on the proper return of a synthetic transaction and that said route should be a valid/non-summarized /24 (i.e. fully accepted by all carriers) but there's no guarantee that this would be the case.

  • I know this is the "professional" site, but I was more looking into a yes/no answer. E.g., based on what you know on how BGP works, and based on the fact that most of these providers own more than a single /24, which they can easily dedicate to DNS alone, wouldn't it make sense to set the priorities in such a way that each NS would always be served by a diff location?
    – cnst
    Jan 17 '17 at 21:51
  • You're not really asking a yes/no question. The provider could easily have (and probably does have) multiple anycast servers within a geographic site as well as other sets of servers at remote sites. Perhaps one of many servers failed within a local cluster but didn't retract its route? The only thing we know for sure is that if the entire site failed (and the route ostensibly was retracted) that you'd definitely see the same IP now tracing to a longer/different path.
    – rnxrx
    Jan 17 '17 at 22:06

As mxrx mentioned - the length of time it takes to fail over is not a known quantity - it would entirely depend on the health-check mechanism running against the service, and the triggering of the BGP withdrawal.

As to serving in different locations - the purpose of anycast in this situation isn't just redundancy, it is also performance.

Under normal operating conditions, you would always want your clients to go to the NEAREST PoP, for primary or secondary services.

Obviously with something as complex and opaque as Internet routing relationships, "nearest" from a routing perspective doesn't always mean nearest from a latency perspective, but the theory is, clients would always use services from their "nearest" PoPs unless there was an issue.

DNS is an interesting one though - assuming the primary and secondary name servers you are provided aren't actually the same box in the back-end, then the delay in detecting failure and withdrawing the anycast prefix that covers both servers would need to be shorter than the delay for clients switching to their secondary NS (on no answer from the primary), otherwise clients are going to get no answer from both.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.