So I'm looking at a company who offers anycasted DNS;
how do I tell if it's really anycasted? Just hop on
different route servers to see if I can find different
AS paths and then do traceroutes to see if they suggest
the packets are not ending in the same location?
From my routers' perspective I don't see a difference,
but then I don't think I should, correct?
Thanks,
David
I was looking at this a lot for the DNS infrastructure distribution research I presented at the last NANOG.
Seeing that something is anycasted at all is sometimes pretty easy. If you do traceroutes from geographically distant sources, you should hopefully end up in different places. However, that doesn't always work, particularly if most of the anycast nodes are "local" nodes, which serve only small areas that you don't have access to.
Finding all the anycast locations, or at least being sure you've found all the locations, is much harder. No matter how much testing you do, you'll never be sure you haven't missed some sites.
The approach I settled on was to ask lots of questions, and then do some traceroutes to verify once I knew where to look. If I knew there was supposed to be a server in location x, a looking glass near location x would probably find it for me.
If you drop me a note off-list saying which anycast network you're looking at, what you're looking for may be information I have.
-Steve
Date: Tue, 16 May 2006 18:05:10 -0400
From: David Hubbard
So I'm looking at a company who offers anycasted DNS;
how do I tell if it's really anycasted? Just hop on
different route servers to see if I can find different
AS paths and then do traceroutes to see if they suggest
the packets are not ending in the same location?
More or less. Latency triangulation actually is useful in this
instance, too. 
From my routers' perspective I don't see a difference, but then
I don't think I should, correct?
Think of it as multihoming, only the end "node" is geographically
distributed. The "node" may also lack "interior" routing.
Eddy
So I'm looking at a company who offers anycasted DNS;
how do I tell if it's really anycasted? Just hop on
different route servers to see if I can find different
AS paths and then do traceroutes to see if they suggest
the packets are not ending in the same location?
>From my routers' perspective I don't see a difference,
but then I don't think I should, correct?
If they conform to the convention that the DNS root servers practice, then
a dig query from several locations should suffice. Choosing an anycasted
DNS root at random, you can do
dig @f.root-servers.net hostname.bind chaos txt
And the response should include a line like
hostname.bind. 0 CH TXT "pao1b.f.root-servers.org"
From other locations, it might be "sfo2c.f.root-servers.net" or somesuch.
If they don't do that, then you are stuck with more ad-hoc methods like
traceroutes from many different locations, or checking out AS-PATHS in
Routeviews and using your intuition.
-Peter
well Peter, ONE root server operator has that practice. Others
have different practices regarding anycast.
--bill
And there are many, with many TLD's.
(rough counts)
provider/tld's
UDNS 48
ISC 19
PCH 8
PSG 23
ICANN 4
UUNET 61
RIPE 87
DEC 10
NIC.FR 71
Note: There is cross servicing of TLDs counted above.
Some numbers may seem low since there seems to be some bit of
obfuscation. Or perhaps not and I just haven't confirmed.
Some are anycasted, some appear to be physical separations, and some
appear to be nested and anycasted i.e. multiple names for the same domain
anycasted.
I think naming is a bad choice because it's costly to the users and opens
the root up to custom configuration by customers which I think is bad.
Tagging the route with a community containing the ISO corresponding country
could be interesting for location purposes, but of course, that's already
been thought of. 
-M<
the Internet has gotten harder with each passing year. Whether it is from intentional obfuscation or just evolutionary new operational practices, you can tell a lot less about a set up now that in the past.
What Steve says is the right thing to do. Get off-net ask questions and then verify on-net. Not just for anycasting, for just about anything. The network is a lot less obvious that it used to be. For better or worse, depending on your point of view.
Of Marty's list above, only UltraDNS and PCH are anycast (there are several other anycast networks hosting TLDs that aren't on Marty's list).
The numbers there look odd to me. My data is a six months old (I really need to rerun my script and regenerate it), but my list of /24s and the TLDs they host is at:
http://www.gibbard.org/~scg/infrastructure-distribution/ranked-dns-subnets-051110
I assume that in most cases a /24 with multiple DNS server IP addresses being authoritative for TLDs is all run by one entity in a common location or set of locations. UUNet is an exception to the location assumption.
-Steve
NS-EXT.ISC.ORG is anycast within AS 3557 as described in ISC-TN-2004-1 (and <http://www.nanog.org/mtg-0505/abley.cluster.html>).
It's a bit pedantic to be pointing that out but, well, I'm a pretty pedantic person.
Joe
well Peter, ONE root server operator has that practice. Others
have different practices regarding anycast.
Actually, it looks to me like all thirteen root servers answer "HOSTNAME.BIND CHAOS TXT" queries (J might check for trailing dots, maybe 
and also that F and C share a strikingly similar naming scheme.
[octopus:~]% for n in a b c d e f g h i j k l m; do
echo -n "trying ${n}... "
dig @${n}.root-servers.net hostname.bind chaos txt +short
done
trying a... "ns6-aroot"
trying b... "b3"
trying c... "ord1a.c.root-servers.org"
trying d... "d-root.net.umd.edu"
trying e... "e4.arc.nasa.gov"
trying f... "yyz1b.f.root-servers.org"
trying g... "g.root-servers.net"
trying h... "H1"
trying i... "s1.was"
trying j... "jns1-kr.j.root-servers.net.j.root-servers.net"
trying k... "k2.nap"
trying l... "l1.l.root-servers.org"
trying m... "M-SFO-1"
[octopus:~]%
Joe
And there are many, with many TLD's.
(rough counts)provider/tld's
UDNS 48
ISC 19
PCH 8
PSG 23
ICANN 4
UUNET 61
RIPE 87
DEC 10
NIC.FR 71Note: There is cross servicing of TLDs counted above.
Some numbers may seem low since there seems to be some bit of
obfuscation. Or perhaps not and I just haven't confirmed.Some are anycasted, some appear to be physical separations, and some
appear to be nested and anycasted i.e. multiple names for the same domain
anycasted.I think naming is a bad choice because it's costly to the users and opens
the root up to custom configuration by customers which I think is bad.Tagging the route with a community containing the ISO corresponding country
could be interesting for location purposes, but of course, that's already
been thought of.Of Marty's list above, only UltraDNS and PCH are anycast (there are several other anycast networks hosting TLDs that aren't on Marty's list).
Right. They start to get smaller in numbers and less interesting.
The numbers there look odd to me. My data is a six months old (I really need to rerun my script and regenerate it), but my list of /24s and the TLDs they host is at:
http://www.gibbard.org/~scg/infrastructure-distribution/ranked-dns-subnets-051110
I assume that in most cases a /24 with multiple DNS server IP addresses being authoritative for TLDs is all run by one entity in a common location or set of locations. UUNet is an exception to the location assumption.
The difference is that you are following the network and I'm following the
operator.
Thanks for sharing your data.
-M<
Just for the record.
All name servers (a,b,c,d.ns.mx) of .mx are anycasted.
You can see a presentation of the infrastructure here: http://www.centr.org/docs/2005/07/centr-tech14-lozano-dotmx.pdf
You can also see a graphical view of the best routes of the infrastructure in the lower lower part of the image: http://docs.nicmxlabs.org.mx/bgpmaps/MX.png
> you can do
> dig @f.root-servers.net hostname.bind chaos txt
> And the response should include a line like
> hostname.bind. 0 CH TXT "pao1b.f.root-servers.org"
well Peter, ONE root server operator has that practice. Others have
different practices regarding anycast.
DNS roots c, f, i, j, k, and m all do something like that, and last I
checked those were all the anycasted DNS roots. But more may have become
so since I last checked. It's true that they don't have to do it, but
it's a common enough convention for all the root DNS operators seem to
have agreed on it, and I've been told that DNS root ops is a highly
contentious subject, so any agreement at all is kind of a nice thing to
note.
Or am I misunderstanding what you are saying?
This is, of course, somewhat off the subject of whether the original
provider in question does that - they may or may not, and the only way to
know is to test and find out. Or ask them.
-Peter
