I'm attempting to come up with a list of all the top level domain DNS servers that are anycasted. I already know about the anycast clouds run by PCH, Neustar, Verisign, DENIC, and UltraDNS, and .mx appears from traceroutes to be anycasted as well. (I know about the anycasted root servers as well; they're out of scope for this question...) Are there others that I'm missing? Thanks, -Steve
On Tue, 4 Oct 2005, Steve Gibbard wrote:
I'm attempting to come up with a list of all the top level domain DNS servers
How are you attempting to do it? One of the problems is that you need to check from multiple locations around the world because dns server would appear to be different depending on where you look at it from. When you look at this in case of ccTLD you not only need to appear in different locations around the world, but it would probably be good to check from multiple locations in that particular country. This makes administratively difficult to arrange to do proper measurement for all the ccTLDs.
that are anycasted. I already know about the anycast clouds run by PCH, Neustar, Verisign, DENIC, and UltraDNS, and .mx appears from traceroutes to be anycasted as well.
I'm pretty sure ISC runs anycasted dns servers too and they run .museum TLD and serve as secondary for one or two other TLDs. BTW - anyone can guess why lookup for SIG RR on .museum results in different response then for some other non-existant RR like NAPTR? -bash-3.00$ dig museum sig ; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;museum. IN SIG ;; Query time: 4 msec ;; SERVER: 216.151.192.1#53(216.151.192.1) -bash-3.00$ dig museum naptr ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;museum. IN NAPTR ;; AUTHORITY SECTION: museum. 3236 IN SOA nic.museum. hostmaster.nic.museum. 2005092312 28800 7200 1209600 3600 ;; Query time: 4 msec ;; SERVER: 216.151.192.1#53(216.151.192.1) -- William Leibzon Elan Networks william@elan.net
On Tue, Oct 04, 2005 at 11:54:03PM -0700, william(at)elan.net <william@elan.net> wrote a message of 49 lines which said:
they [ISC] run .museum TLD
It does not seem so.
and serve as secondary for one or two other TLDs.
Not with their anycast servers, unless they added this service very recently.
On 5-Oct-2005, at 02:54, william(at)elan.net wrote:
I'm pretty sure ISC runs anycasted dns servers too and they run .museum TLD and serve as secondary for one or two other TLDs.
Service for the nameservers NS-EXT.VIX.COM and NS-EXT.ISC.ORG are provided by an anycast cluster along the lines described in: http://www.isc.org/pubs/tn/index.pl?tn=isc-tn-2004-1.txt http://www.nanog.org/mtg-0505/abley.cluster.html So, service is distributed over multiple hosts using anycast, but the scope of the anycast is limited geographically to a single location in a single AS. Joe
scg@gibbard.org (Steve Gibbard) wrote:
I'm attempting to come up with a list of all the top level domain DNS servers that are anycasted. I already know about the anycast clouds run by PCH, Neustar, Verisign, DENIC, and UltraDNS, and .mx appears from traceroutes to be anycasted as well.
(I know about the anycasted root servers as well; they're out of scope for this question...)
Are there others that I'm missing?
Add .de to your list. "z.nic.de" is anycasted. I'd propose taking the list of TLDs, generating the list of associated authoritative DNS servers (and their IP addresses) and try that list on the routing registries... Cheers, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On Wed, 5 Oct 2005, Elmar K. Bins wrote:
I'd propose taking the list of TLDs, generating the list of associated authoritative DNS servers (and their IP addresses) and try that list on the routing registries...
Assuming that you do that, what would you be your criteria to find based on RR if the ip is anycasted or not? I mean lets suppose that I run dns server at AS0 and peer at location A and also at location B with same ISP with AS1. I might have one dns server at location A and another different one at location B, which means its anycasting. But from peering perspective it would just appear as the same path AS0->AS1 no matter what location it is. Opposite to that route to the same server might be seen from different peer AS# based on location because of routing policies. -- William Leibzon Elan Networks william@elan.net
william@elan.net (william(at)elan.net) wrote:
authoritative DNS servers (and their IP addresses) and try that list on the routing registries...
Assuming that you do that, what would you be your criteria to find based on RR if the ip is anycasted or not?
Maybe I overestimate the openness of the people and believe everybody would drop their documentation there... ~>whois -h whois.radb.net 194.246.96.1 route: 194.246.96.0/24 descr: DENIC eG anycast prefix origin: AS31529 ... The AS object gives a lot more clue then... aut-num: AS31529 as-name: DENIC-ANYCAST-AS descr: DENIC eG descr: DNS anycast AS object ... remarks: | DENIC eG operates the .de ccTLD registry. DENICs IPv4 | remarks: | DNS servers are partial unicast and partial anycast. | remarks: | This object covers the IPv4 anycast setups. | ... Maybe using route servers helps more (coffee!) :-)
I mean lets suppose that I run dns server at AS0 and peer at location A and also at location B with same ISP with AS1. I might have one dns server at location A and another different one at location B, which means its anycasting. But from peering perspective it would just appear as the same path AS0->AS1 no matter what location it is.
That's some kind of anycasting, but from a networking point of view it's redundant links to the same "thing" ;-) If you are lucky, you can see different next-hops in the BGP.
Opposite to that route to the same server might be seen from different peer AS# based on location because of routing policies.
Using views from route-servers that are distant from each other might improve the picture. The RIPE RIS project may be able to help. Cheers, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
On Wed, 5 Oct 2005, Elmar K. Bins wrote:
william@elan.net (william(at)elan.net) wrote:
authoritative DNS servers (and their IP addresses) and try that list on the routing registries...
Assuming that you do that, what would you be your criteria to find based on RR if the ip is anycasted or not?
Maybe I overestimate the openness of the people and believe everybody would drop their documentation there...
~>whois -h whois.radb.net 194.246.96.1 route: 194.246.96.0/24 descr: DENIC eG anycast prefix origin: AS31529
Interesting, I did not notice they put it in there... As I have necessary tools to quicly filter such data from multiple DBs, you might be interested in the list of those self-reporting anycast in RR (its not very long): 192.5.5.0/24 AS3557 - ISC F ROOT (source: OTTIX, VERIO, RIPE) 64.94.96.0/24 AS24246 - INTERNAP (source: SAVVIS, RADB) 204.8.212.0/22 AS32476 - Tellme Networks (source: RADB) 196.6.240.0/24 AS27598 - IS.CO.ZA (source: RADB, RIPE) 195.85.200.0/24 AS29117 - irc-hispano.org (source: RIPE) 192.88.99.0/24 AS12859 - BIT.NL 6to4 relay RFC3068 (source: RIPE) 194.145.251.0/24 AS33837 - PRQ.SE (source: RIPE) 194.246.96.0/24 AS31529 - DENIC (source: RIPE) 84.205.72.0/24 AS12654 - RIPE NCC RIS (source: RIPE) 84.205.73.0/24 AS12654 - RIPE NCC RIS (source: RIPE) 192.88.99.0/24 AS3344 - kewlio.net 6to4 relay RFC3068 (source: RIPE) 2001::500::/48 AS3557 - ISC F ROOT (source: RIPE) 2002::/16 AS3344 - 6to4 relay anycast - no longer done, right?? Getting back to the subject of anycast DNS TLDs, its possible that above did provide a clue that one of the .ZA servers might be anycasted (although NSZA.IS.CO.ZA is 196.4.160.27 right now and not listed anycast in RR). P.S. I will search for anycast in description of ip whois data when I get a chance and if its not long and interesting may post summary here as well. -- William Leibzon Elan Networks william@elan.net
On Wed, 5 Oct 2005, Joe Abley wrote:
2002::/16 AS3344 - 6to4 relay anycast - no longer done, right??
6to4 is alive and well.
But not well deployed on the v6 side, as I noted earlier this year. There aren't enough North America exit routes to cover some of the v6 networks there. Of course, there aren't enough North America v6 nets, either. <g> -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
* Joe Abley:
On 5-Oct-2005, at 05:53, william(at)elan.net wrote:
2002::/16 AS3344 - 6to4 relay anycast - no longer done, right??
6to4 is alive and well.
For some values of. I believe the bit.nl 6to4 gateway still generates IPv4 packets with non-routable source addresses, which are uRPFed by some operators.
On 5-Oct-2005, at 11:33, Florian Weimer wrote:
* Joe Abley:
On 5-Oct-2005, at 05:53, william(at)elan.net wrote:
2002::/16 AS3344 - 6to4 relay anycast - no longer done, right??
6to4 is alive and well.
For some values of. I believe the bit.nl 6to4 gateway still generates IPv4 packets with non-routable source addresses, which are uRPFed by some operators.
Ah yes, that's true, and we've been bitten by that. At ISC, we have an unusually large population of external users using 6to4 to reach us, since most things we host are available on v6, and also because most things we host are of interest to developers who probably have more energy for turning things like 6to4 on than most people. Our 6to4-using client population became much more happy once I deployed a 6to4 relay router inside AS3557, and had people use it directly instead of the anycast 6to4 relay router address. I don't think I've had a single complaint reported since I turned that on, in fact. Advertising 2002::/16 and 192.88.99.0/24 for global transit from AS 3557 is on the to-do list. No ETA for that right now, however. Joe
participants (7)
-
Elmar K. Bins -
Florian Weimer -
Joe Abley -
Stephane Bortzmeyer -
Steve Gibbard -
Todd Vierling -
william(at)elan.net