

Global Routing with Anycasted DNS. Teardown: NSONE - mxpxrocks10
http://www.scalescale.com/global-routing-with-anycasted-dns-teardown-nsone/

======
sajal83
Kris from NSONE really knows his stuff. We are on process of moving all our
DNS traffic to them. When starting to look into them I was skeptical of US
ever using such a new provider... But their hands-on approach changed our
minds...

------
nopzor
Kris is a great guy and the team at NSONE are really solid.

Really good to see such a detailed article that addresses the topic from top
to bottom.

I think more and more people are going to want to use something like this to
build a global infra, especially across multiple providers. DNS is an often
forgotten (other than everything being a 'fucking DNS problem' :-) part of the
stack, and it's good to see a fresh approach.

Great article @mxpxrocks10

(disclosure: I was founder@Voxel and am investor@nsone, so my opinion is
probably more than a bit biased ;-)

------
zsmith928
Great read and really does an awesome job showing not only the tech of what
NSOne has built, but the 'why' behind the 'how'. DNS is such a deceptively
simplistic service, but I think that's only due to the lack of real innovation
in the space. NSOne is doing an awesome job changing that. Thanks @chris and
@kris ;-)

------
mxpxrocks10
Hi- this is Chris from ScaleScale/MaxCDN. I wanted to thank Kris for making
himself available for this. I'd be interested in hearing pros/cons about the
format for ScaleScale so we can keep tweaking our posts. We have some more
great ones planned very soon - your feedback will help make them more
relevant.

~~~
beevek
Kris here. Thanks Chris for putting this together, it was a really fun set of
questions. I think a lot of what makes NSONE different is the philosophy
behind the tech. We're not a DNS company, we're a traffic management company
and we think DNS is a great place to do traffic management. Hope that comes
across in this article.

------
xin3td
Interesting article. Can you elaborate a little more on why I should consider
the best DNS response vs. the fastest response especially when my customers
are concerned with first byte times? Also how do your filter chains differ
from the likes of DNS Made Easy or DYN and what makes NSOne better?

~~~
beevek
A simple example might help. Imagine you have a node in California and a node
in NY, and a user in NJ. Let's assume for now that geographic proximity is
actually a good arbiter for performance. If we make a bad routing decision and
send your user to the CA node, we're adding a lot of overhead in their session
with your application: every TCP packet (e.g., every HTTP request) takes a
long round trip. Even if we spit out a DNS answer really, really fast, if it's
the wrong answer, the user has a bad experience.

It's actually even worse than that, because the user isn't the one directly
doing the DNS query: there's an intermediary DNS resolver, which will cache
the response. If the "wrong" response gets cached, then _every_ user of that
resolver will get that wrong response until the cache expires. So not only
have we made the original requester's experience bad, but we've negatively
impacted every other user of your application that's leveraging the same
resolver.

Time to first byte is a combination of a lot of things, and if you're in more
than one datacenter, it doesn't much matter how fast you spit out a DNS
response if you're giving the wrong one and impacting the rest of the session
going forward.

Doesn't mean you shouldn't expect the best of both worlds: sending the user to
the "best" endpoint, fast.

On the filter chain question: typical/canonical approach to do any kind of
decision making in a DNS system is to add some new proprietary record type,
like a geo record or a health checking record. That's kind of the natural
thing to do in DNS at first glance.

But if you want to get any kind of complex routing behavior, you're going to
need an awful lot of different record types implementing those different
behaviors, and what you end up with behind the scenes is what I often call a
spaghetti of different DNS records all pointing at each other in some kind of
big decision tree -- maybe a geo record, pointing at a bunch of health
checking records, pointing at a bunch of CNAMEs, pointing at a bunch of A
records. This quickly becomes unmanageable, and every new kind of routing you
want to do results in another layer in the decision tree, all to resolve a
single hostname.

The Filter Chain is a way to collapse all that down to something much more
manageable and performant by bringing all the context into one place and
thinking of routing as a collection of simple actions that you're taking on
some input data (answers you could give, and details about those answers).

------
jread
Great to see some fresh ideas in this space. NSONE filter chains are a nice
take on what other services implement as disparate features (directional DNS,
load balancing, health checks, ...)

------
dhenzel
Hi - great post, thanks. I had a question about the heat map. What is the /32s
and 10Q, can you explain it some more please?

~~~
beevek
Hi -- glad you like the post. /32s are individual DNS resolver IPs we observed
in each country from among the sample we took (half a percent of the traffic
we saw during a 24h period).

The >10Q column is how many of those resolvers we saw that did >10Q from among
our sample -- you can see there are many fewer resolvers that are doing even
moderate amounts of traffic.

~~~
beevek
Er -- I should have said, that did more than 10 queries from among our sample.

~~~
beevek
Certainly a huge drop-off. There is a lot of noise out there -- a lot of
"resolvers" doing very few queries, whether because they have very few users,
or because they're one-off special purpose resolvers. Vast majority of the
internet is really serviced by a few thousand major DNS resolvers. Obviously
Google/OpenDNS are chief among those, but Comcast and other major ISPs account
for most of the volume, as you'd probably expect.

Edit: whoops, meant to reply to Chris below.

------
koreanITguy
NSone is always on point, just like this article. Good stuff Kris.

------
relik
great article. thanks for sharing. looking forward to more. do you guys use
any automation for maintaining your switch/router configs?

~~~
beevek
Most of the time we don't actually operate switches of our own, and our setup
is simple enough where we don't do a ton of automation around the config where
we do. What we do automate end-to-end is our BGP: our prefixes are actually
announced from servers (using exabgp), not routers -- and our config there is
managed by ansible, plus some real-time automation around community strings.

~~~
relik
awesome, appreciate the quick response.

