Concern about gTLD servers in India
Hello everyone, Greetings from India. I hope lot of you have enjoyed APRICOT event at New Delhi. I wanted to bring an important issue. It's about DNS root servers in India. So anurag@laptop:~$ dig . ns +short i.root-servers.net. e.root-servers.net. j.root-servers.net. l.root-servers.net. k.root-servers.net. d.root-servers.net. h.root-servers.net. f.root-servers.net. m.root-servers.net. c.root-servers.net. a.root-servers.net. g.root-servers.net. b.root-servers.net. I can see India has 3 root servers hosting root zone - i, j & k in India which is good. So we can resolve the root zone i.e dot within India. Next, looking gTLD servers used by popular TLDs like com/net/org: anurag@laptop:~$ dig com. ns +short g.gtld-servers.net. f.gtld-servers.net. a.gtld-servers.net. h.gtld-servers.net. e.gtld-servers.net. d.gtld-servers.net. j.gtld-servers.net. i.gtld-servers.net. c.gtld-servers.net. m.gtld-servers.net. l.gtld-servers.net. k.gtld-servers.net. b.gtld-servers.net. None of these gTLD root servers are in India. I have tested routes to each of them from BSNL (AS9829), Tata Comm (AS4755 & AS6453), Airtel (AS9498) - all land up outside India - most of them in Europe and US, and couple of them in Singapore, and one in Australia. Why so? Please correct me if I am wrong on this analysis but this seems not efficient setup to me. Any damage on outside connectivity (which is common with Earthquakes or ships hitting submarine fiber, and eventually opposite route getting chocked with traffic) - can cause huge issues on sites which are hosted within India. And so this is how google.com is resolved in India: anurag@laptop:~$ dig google.com +trace ; <<>> DiG 9.7.1-P2 <<>> google.com +trace ;; global options: +cmd . 11352 IN NS i.root-servers.net. . 11352 IN NS e.root-servers.net. . 11352 IN NS j.root-servers.net. . 11352 IN NS l.root-servers.net. . 11352 IN NS k.root-servers.net. . 11352 IN NS d.root-servers.net. . 11352 IN NS h.root-servers.net. . 11352 IN NS f.root-servers.net. . 11352 IN NS m.root-servers.net. . 11352 IN NS c.root-servers.net. . 11352 IN NS a.root-servers.net. . 11352 IN NS g.root-servers.net. . 11352 IN NS b.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 57 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. ;; Received 491 bytes from 128.63.2.53#53(h.root-servers.net) in 264 ms - Hitting outside root server, but anyways alternate i,j,k are up in India so good overall. google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. ;; Received 164 bytes from 192.5.6.30#53(a.gtld-servers.net) in 315 ms - Hitting outside server and it will always hit outside since no server here. Problem. google.com. 300 IN A 173.194.36.3 google.com. 300 IN A 173.194.36.4 google.com. 300 IN A 173.194.36.0 google.com. 300 IN A 173.194.36.2 google.com. 300 IN A 173.194.36.8 google.com. 300 IN A 173.194.36.1 google.com. 300 IN A 173.194.36.5 google.com. 300 IN A 173.194.36.7 google.com. 300 IN A 173.194.36.6 google.com. 300 IN A 173.194.36.14 google.com. 300 IN A 173.194.36.9 ;; Received 204 bytes from 216.239.32.10#53(ns1.google.com) in 305 ms Also, looking at reverse DNS root servers: anurag@laptop:~$ dig in-addr.arpa. ns +short a.in-addr-servers.arpa. b.in-addr-servers.arpa. c.in-addr-servers.arpa. d.in-addr-servers.arpa. e.in-addr-servers.arpa. f.in-addr-servers.arpa. Again, none of these hosted in India. So for each email sent within any domains across India - during smtp check, rDNS is resolved from outside world? (SMTP auth. being one of mail roles of rDNS besides few others). I have collected data about paths from popular Indian backbones to each of these servers. If anyone interested, please let me know. *Sidenote: I know NANOG is primarily for North America but I really appreciate good replies and was wondering if someone can tell me if my understanding is wrong.* Very much interested in hearing comments from community on this. Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com
On 10/03/2012 08:19, Anurag Bhatia wrote:
Next, looking gTLD servers used by popular TLDs like com/net/org:
<snip>
None of these gTLD root servers are in India. I have tested routes to each of them from BSNL (AS9829), Tata Comm (AS4755& AS6453), Airtel (AS9498) - all land up outside India - most of them in Europe and US, and couple of them in Singapore, and one in Australia. Why so? Please correct me if I am wrong on this analysis but this seems not efficient setup to me. Any damage on outside connectivity (which is common with Earthquakes or ships hitting submarine fiber, and eventually opposite route getting chocked with traffic) - can cause huge issues on sites which are hosted within India.
This problem is unfortunately not unique to India. There appear to be no anycast instances of the gTLD servers in Africa either. I am 180-500ms away from the gTLD servers right now.
Also, looking at reverse DNS root servers:
anurag@laptop:~$ dig in-addr.arpa. ns +short a.in-addr-servers.arpa. b.in-addr-servers.arpa. c.in-addr-servers.arpa. d.in-addr-servers.arpa. e.in-addr-servers.arpa. f.in-addr-servers.arpa.
These servers are operated by the RIRs. Its probably worth contacting APNIC to find out how to get an anycast instance installed at you local internet exchange point. -- Graham Beneke
Hello Randy No idea about Africa but certainly none of gTLD servers in India. On Sat, Mar 10, 2012 at 12:42 PM, Randy Bush <randy@psg.com> wrote:
This problem is unfortunately not unique to India. There appear to be no anycast instances of the gTLD servers in Africa either.
really!?
-- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com
No idea about Africa
then on what basis did you make the assertion?
but certainly none of gTLD servers in India.
i am slightly suspicious of this. often, root servers are accompanied by gtld servers, and there are more than zero root servers in india. there is a fashion among root and gtld servers to attempt to limit the scope of their ancast routing announcements. this makes them hard to find from a (topologic) distance. randy
Please don't create confusions. I didn't made any assertion. I mentioned issue with India, but Graham came with point that issue is similar in Africa. Good point if he knows that. Certainly relevent to issue I mentioned for India. Again - I have not verified this. I don't know much about ISPs in Africa to find their looking glasses and test routing. On Sat, Mar 10, 2012 at 1:00 PM, Randy Bush <randy@psg.com> wrote:
No idea about Africa
then on what basis did you make the assertion?
but certainly none of gTLD servers in India.
i am slightly suspicious of this. often, root servers are accompanied by gtld servers, and there are more than zero root servers in india.
there is a fashion among root and gtld servers to attempt to limit the scope of their ancast routing announcements. this makes them hard to find from a (topologic) distance.
randy
Ok, here's some data I collected couple of months back. I did consistant lookup for days to be sure that it's not temporary routing glitch giving such results. Traceroute to gTLDs from BSNL AS9829 - http://cdn.anuragbhatia.com/uploads/2012/03/gtld-traceroute-bsnl-as9829.txt Traceroute to gTLDs from Bharti Airtel AS9498 - http://cdn.anuragbhatia.com/uploads/2012/03/gtld-traceroute-airtel-as9498.tx... Traceroutes to rDNS in-addr.arpa servers from BSNL - http://cdn.anuragbhatia.com/uploads/2012/03/rdns-bsnl-as9829.txt Traceroutes to rDNS in-addr.arpa servers from Airtel - http://cdn.anuragbhatia.com/uploads/2012/03/rdns-airtel-as9498.txt Thanks for your time & comments. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com
Sure, if you can find a datacenter that's capable of handling all the traffic, and has staff who are able to provide efficient remote hands for huge racks of extremely powerful servers .. and are possibly also open to cross subsidizing the costs that GTLD operators will incur to host instances of their servers in India .. etc etc. On Sat, Mar 10, 2012 at 1:15 PM, Anurag Bhatia <me@anuragbhatia.com> wrote:
Please don't create confusions.
I didn't made any assertion. I mentioned issue with India, but Graham came with point that issue is similar in Africa. Good point if he knows that. Certainly relevent to issue I mentioned for India.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
On 3/10/12 08:05 , Suresh Ramasubramanian wrote:
Sure, if you can find a datacenter that's capable of handling all the traffic, and has staff who are able to provide efficient remote hands for huge racks of extremely powerful servers .. and are possibly also open to cross subsidizing the costs that GTLD operators will incur to host instances of their servers in India .. etc etc.
DNS even at scale is not a particularly compute intensive service. That said whether it's worth it or not is in the eyes of operator.
On Sat, Mar 10, 2012 at 1:15 PM, Anurag Bhatia <me@anuragbhatia.com> wrote:
Please don't create confusions.
I didn't made any assertion. I mentioned issue with India, but Graham came with point that issue is similar in Africa. Good point if he knows that. Certainly relevent to issue I mentioned for India.
Yes of course, if you don't count the multi gbps DDoS attacks and such .. On Sat, Mar 10, 2012 at 11:30 PM, Joel jaeggli <joelja@bogus.com> wrote:
DNS even at scale is not a particularly compute intensive service.
That said whether it's worth it or not is in the eyes of operator.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mar 10, 2012, at 8:05 AM, Suresh Ramasubramanian wrote:
Sure, if you can find a datacenter that's capable of handling all the traffic, and has staff who are able to provide efficient remote hands for huge racks of extremely powerful servers .
Honestly, we haven't even gotten that far when we've offered to deploy servers (for instance for domains like .IN) inside India. The bribes that were requested in exchange for giving us permission to deploy a free service were, uh, both prohibitive and ludicrous in their enormity. There are a lot of countries that have far less wealth than India, that manage to stand up more interesting infrastructure, because they have less friction caused by corruption. India: USD 3,703 GDP per capita (source: IMF) Bangladesh: USD 1,697 Tanzania: USD 1,505 Nepal: USD 1,328 -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPW6EsAAoJEG+kcEsoi3+HySgQAJ/td8kXhyxzMJ18J0Xrxpvj 36d6VJqfajgkeSJ9SFiWwam+Us7XBRnwKgz9ntX3wmavA0H4QTuWQyTl9T60Fac+ hvqu3VzV7U2dNh74WVRGmpRZrfY+4Of1fpxV2CG3y+xDAHa6wTbZ7AVey+L6xLoK dKp3oMyMxr9yX596BEI4xWmQnt7SpQA3hcoYTUgTHXTxSh0xdwd7ovD31J8vXg0C wVgTHZ2ibka99LPh3Oo2gNSHm6gqRTHeu8ZmiEpFZwbpMTk0y8XTnvbAHOjnlQcP oV/44591ybYkVhXlBs2f7Yuh7EtxF83g1cjq8QeNdb++7XJxrVEb3rTuFEmedIWx +51P0Sta39CbskG70mFehUjjvAFLsnX6U3epBJtDxcj0NT+jB6BMZM7MFPqeFESj GZ4qj7mCbOWcPoSnq+o4IEH92fk60nhVv7uOi/C3jnJXuJeT2/F6VrEueYK3EGKI PVn099CjvFpjF5u/hauayv+jqd7QBzilphR5swKERLZc4ftinHFJIsjllzK6bztv cFvubRZAsPyznRzk9HDL6zxd7E9zHuBgZnFmRlD6LxR5tTgVRrvtW5UhwvQcqXNe ceYIVcoc44uXdiDIgEaz/Hx9aLkZb+jXZh1+Dcvwb3xqCi5rvSpWsb0I7tfRYKGF G1/WRLex2Z093zxCl6po =O3IR -----END PGP SIGNATURE-----
On Sat, Mar 10, 2012 at 10:45 AM, Bill Woodcock <woody@pch.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Mar 10, 2012, at 8:05 AM, Suresh Ramasubramanian wrote:
Sure, if you can find a datacenter that's capable of handling all the traffic, and has staff who are able to provide efficient remote hands for huge racks of extremely powerful servers .
Honestly, we haven't even gotten that far when we've offered to deploy servers (for instance for domains like .IN) inside India. The bribes that were requested in exchange for giving us permission to deploy a free service were, uh, both prohibitive and ludicrous in their enormity.
This. This and the import duties on hardware and the requirement for licensing to operate as an "ISP" makes placing even a modest deployment a lot more work compared to deploying in other neighboring countries. I would presume that Verisign decided that it just wasn't worth the effort to deploy into India. It obviously has a gigantic user base for which getting into local ISPs and IXPs would probably save on transit costs. Perhaps if some local root operators could donate some space/power/connectivity, Verisign-grs could colocate a gTLD cluster there? Cheers, jof
On 3/10/12 3:23 PM, Jonathan Lassoff wrote:
I would presume that Verisign decided that it just wasn't worth the effort to deploy into India.
operational control of .in passed to a for-profit operator domiciled in one_of{us,ca,ie} other than VGRS. as india is a competitor's property, investment there by VGRS mby be difficult to justify. -e
On Mar 10, 2012, at 2:05 PM, Eric Brunner-Williams wrote:
On 3/10/12 3:23 PM, Jonathan Lassoff wrote:
I would presume that Verisign decided that it just wasn't worth the effort to deploy into India.
operational control of .in passed to a for-profit operator domiciled in one_of{us,ca,ie} other than VGRS. as india is a competitor's property, investment there by VGRS mby be difficult to justify.
-e
The more telling fallacy here that really speaks to the heart of why I am dismayed and disappointed by ICANN's management of the whole TLD mess is the idea that a CCTLD is the property of a TLD operator to begin with. The .IN TLD is property of the Indian people or worst case, the government of India acting in their stead. (or at least it should be if ICANN and/or Verisign and their competitors haven't managed to completely usurp the public trust. Owen
On 03/10/2012 04:38 PM, Owen DeLong wrote:
On Mar 10, 2012, at 2:05 PM, Eric Brunner-Williams wrote:
On 3/10/12 3:23 PM, Jonathan Lassoff wrote:
I would presume that Verisign decided that it just wasn't worth the effort to deploy into India.
operational control of .in passed to a for-profit operator domiciled in one_of{us,ca,ie} other than VGRS. as india is a competitor's property, investment there by VGRS mby be difficult to justify.
-e
The more telling fallacy here that really speaks to the heart of why I am dismayed and disappointed by ICANN's management of the whole TLD mess is the idea that a CCTLD is the property of a TLD operator to begin with.
I'm pretty sure that's not what Eric meant by "property," at least I hope it isn't. I think he meant given that Verisign is no longer responsible for the registry services operator backend that it doesn't make sense for them to be investing money in making that backend better. I can also tell you based on my experience with them that Afilias doesn't consider the TLDs that they provide RSO support for as their property either.
The .IN TLD is property of the Indian people or worst case, the government of India acting in their stead. (or at least it should be if ICANN and/or Verisign and their competitors haven't managed to completely usurp the public trust.
I can tell you with 100% certainty that when I was responsible for handling ccTLD delegation changes that we took the issue of ccTLDs being operated for the benefit of the Internet community in that country, and the global Internet community as a whole, very seriously. I have no reason to believe that things changed after I left. Doug -- If you're never wrong, you're not trying hard enough
I can tell you with 100% certainty that when I was responsible for handling ccTLD delegation changes that we took the issue of ccTLDs being operated for the benefit of the Internet community in that country, and the global Internet community as a whole, very seriously. I have no reason to believe that things changed after I left.
Starting with .tv that line got somewhat gray; ccTLD "repurposing" is commonplace nowadays. Initial ccTLD delegations, even the more recent ones, still seems to hold up to Postel's standard, though. Rubens
On Mar 10, 2012, at 6:38 PM, Owen DeLong wrote:
The more telling fallacy here that really speaks to the heart of why I am dismayed and disappointed by ICANN's management of the whole TLD mess is the idea that a CCTLD is the property of a TLD operator to begin with.
Your dismay and disappointment may be relieved by doing a bit of research. Management of country code top-level domains is treated by ICANN as national sovereignty issue. ICANN has limited say in who runs a ccTLD (it must be done according to the wishes of the "local Internet community") and technical matters related to how that ccTLD is managed (e.g., ICANN, through the IANA root management functions places certain (minimal) technical requirements on the operation of the TLD name servers).
The .IN TLD is property of the Indian people or worst case, the government of India acting in their stead. (or at least it should be if ICANN and/or Verisign and their competitors haven't managed to completely usurp the public trust.
You might want to read RFC 1591, ICP-1, and/or the ICANN GAC principles before passing judgement. Regards, -drc
At 16:38 -0800 3/10/12, Owen DeLong wrote:
The more telling fallacy here that really speaks to the heart of why I am dismayed and disappointed by ICANN's management of the whole TLD mess is the idea that a CCTLD is the property of a TLD operator to begin with.
This is not true. First, there is the ccTLD itself - it is an organization that is recognized has having legitimate claim to the country code. These do change at times. Then there is the ccTLD operator. Some ccTLDs "own and operate" and some do out source the technical operations, sometimes just DNS, sometimes everything (e.g., the database). When out sourcing, the ccTLD "owner" makes contractural demands of the operator. If the ccTLD requires an in-country DNS presence that is easily arranged by the operator. (The operator reflects the cost in the price.) With the growing awareness of the role of the Internet, ccTLDs do not let the operator "do their thing." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars!
You mean you haven't then immediately heard the "we are a developing country, please provide it free" story? On 3/11/12, Jonathan Lassoff <jof@thejof.com> wrote:
On Sat, Mar 10, 2012 at 10:45 AM, Bill Woodcock <woody@pch.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Mar 10, 2012, at 8:05 AM, Suresh Ramasubramanian wrote:
Sure, if you can find a datacenter that's capable of handling all the traffic, and has staff who are able to provide efficient remote hands for huge racks of extremely powerful servers .
Honestly, we haven't even gotten that far when we've offered to deploy servers (for instance for domains like .IN) inside India. The bribes that were requested in exchange for giving us permission to deploy a free service were, uh, both prohibitive and ludicrous in their enormity.
This.
This and the import duties on hardware and the requirement for licensing to operate as an "ISP" makes placing even a modest deployment a lot more work compared to deploying in other neighboring countries.
I would presume that Verisign decided that it just wasn't worth the effort to deploy into India. It obviously has a gigantic user base for which getting into local ISPs and IXPs would probably save on transit costs.
Perhaps if some local root operators could donate some space/power/connectivity, Verisign-grs could colocate a gTLD cluster there?
Cheers, jof
-- Suresh Ramasubramanian (ops.lists@gmail.com)
On 3/10/2012 10:12 AM, Randy Bush wrote:
This problem is unfortunately not unique to India. There appear to be no anycast instances of the gTLD servers in Africa either.
really!?
There was one in KE but can't find or reach it: [a-m].gtld-servers.net. seem all to be in 192.0.0.0/8 route-views.kixp.routeviews.org> sh ip bgp 192.0.0.0/8 lo route-views.kixp.routeviews.org> Likely there is still (?) in EG ...? Frank
On 10/03/2012 09:12, Randy Bush wrote:
This problem is unfortunately not unique to India. There appear to be no anycast instances of the gTLD servers in Africa either.
really!?
Yes. I was also a little surprised. I'm sure that I read somewhere that at least one of the gTLD anycast prefixes was available at JINX (although I've never actually confirmed that). I've gone through every permutation of mtr [-4|-6] [a-m].gtld-servers.net. again just to be sure. I'm reaching nothing on this continent. -- Graham Beneke
I am sure few of people here have experience of running root servers. Can someone share if there's huge difference in . root servers Vs gTLD servers? I understand that root only hold all TLD's - cc and gTLD delegation that would be few hundred TLDs delegation while gTLDs hold lot of domain names but if one country has root, what prevents having gTLD also? Certainly bit more hardware, storage and processing power but such facilities are available mostly say in India & South Africa which have significant number of big telcos. On Sat, Mar 10, 2012 at 12:52 PM, Graham Beneke <graham@apolix.co.za> wrote:
On 10/03/2012 09:12, Randy Bush wrote:
This problem is unfortunately not unique to India. There appear to be no
anycast instances of the gTLD servers in Africa either.
really!?
Yes. I was also a little surprised.
I'm sure that I read somewhere that at least one of the gTLD anycast prefixes was available at JINX (although I've never actually confirmed that).
I've gone through every permutation of
mtr [-4|-6] [a-m].gtld-servers.net.
again just to be sure. I'm reaching nothing on this continent.
-- Graham Beneke
-- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com
Anurag Bhatia <me@anuragbhatia.com> writes:
Can someone share if there's huge difference in . root servers Vs gTLD servers? I understand that root only hold all TLD's - cc and gTLD delegation that would be few hundred TLDs delegation while gTLDs hold lot of domain names but if one country has root, what prevents having gTLD also? Certainly bit more hardware, storage and processing power but such facilities are available mostly say in India & South Africa which have significant number of big telcos.
There's a huge difference in operational complexity (and capex) between running root nameservers and gtld nameservers (to further confuse things, there are four gtlds, only two of which are run gtld-servers.net infrastructure, which means that Verisign is the operator). Root zone = a few thousand records with changes gated by people with a high degree of DNS clue, that come at a slow pace (once or twice a day typically). The roots eat a fair amount of bogus traffic (mitigated somewhat by things like the as112 project) due to poorly configured libraries and people's mistyping. It is trivial to run a shadow root locally by just secondarying "." on your cacheing nameservers. In fact, recent versions of FreeBSD have had a config like this to replace the named.root hints file - you just have to comment out the hints section and uncomment the secondary section in /etc/namedb/named.conf. You can do this on something as small as a wall-wart firewall device assuming it's running something like BIND. Obviously something that is exposed to the Internet as an anycast node will be built on much more capable hardware. A typical gtld zone will have anywhere from a few million to high tens of millions of records in it. Everyone and his brother has a vanity domain and together the update load and expectations of the customers are that changes will be committed instantaneously and visible across all nameservers for the gTLD within a few minutes at the outside. This update rate is a huge pain in operational practice and the sheer number of records eats a pretty decent sized memory footprint too. To answer your question, to get TLD anycast stacks in any given location, there will need to be a discussion with the TLD operator; in the case of the GTLDs that would be Verisign (.com and .net) and Afilias (.org and .info). In the case of sTLDs, GeoTLDs, and CCTLDs, the cast of actors expands considerably. No such thing a a one-stop shop. There is also an issue of cost/benefit. In the current economic climate assuming that organizations have unlimited resources to commit to the public good (regardles of how noble their intentions might be) is probably unwise. Does this help? -r (no longer an employee of a TLD op)
On Mar 10, 2012, at 7:02 PM, Robert E. Seastrom wrote:
there are four gtlds
Aren't there actually seven? ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On 10/03/2012 14:54, Dobbins, Roland wrote:
On Mar 10, 2012, at 7:02 PM, Robert E. Seastrom wrote:
there are four gtlds
Aren't there actually seven?
According to ICANN[1] there are "roughly two dozen gTLDs" [1] http://newgtlds.icann.org/en/about -- Graham Beneke
In article <95F7DF59-052D-43BA-869F-289DF915C62E@arbor.net> you write:
On Mar 10, 2012, at 7:02 PM, Robert E. Seastrom wrote:
there are four gtlds
Aren't there actually seven?
Including the new IDN TLDs, there are now 60. R's, John aero. 172800 IN NS a0.aero.afilias-nst.info. asia. 172800 IN NS a0.asia.afilias-nst.info. biz. 172800 IN NS a.gtld.biz. cat. 172800 IN NS b.nic.ch. com. 172800 IN NS a.gtld-servers.net. coop. 172800 IN NS coop1.dyntld.net. info. 172800 IN NS a0.info.afilias-nst.info. int. 172800 IN NS ns.uu.net. jobs. 172800 IN NS a5.nstld.com. mobi. 172800 IN NS a0.mobi.afilias-nst.info. museum. 172800 IN NS ns.icann.org. name. 172800 IN NS a6.nstld.com. net. 172800 IN NS a.gtld-servers.net. org. 172800 IN NS a0.org.afilias-nst.info. pro. 172800 IN NS a.gtld.pro. tel. 172800 IN NS a.dns.nic.tel. travel. 172800 IN NS a.gtld.travel. xn--0zwm56d. 172800 IN NS a.iana-servers.net. xn--11b5bs3a9aj6g. 172800 IN NS a.iana-servers.net. xn--3e0b707e. 172800 IN NS b.dns.kr. xn--45brj9c. 172800 IN NS a0.cctld.afilias-nst.info. xn--80akhbyknj4f. 172800 IN NS a.iana-servers.net. xn--80ao21a. 172800 IN NS kz.cctld.authdns.ripe.net. xn--90a3ac. 172800 IN NS a.nic.rs. xn--9t4b11yi5a. 172800 IN NS a.iana-servers.net. xn--clchc0ea0b2g2a9gcd. 172800 IN NS ns2.cuhk.edu.hk. xn--deba0ad. 172800 IN NS a.iana-servers.net. xn--fiqs8s. 172800 IN NS h.dns.cn. xn--fiqz9s. 172800 IN NS h.dns.cn. xn--fpcrj9c3d. 172800 IN NS a0.cctld.afilias-nst.info. xn--fzc2c9e2c. 172800 IN NS lk.communitydns.net. xn--g6w251d. 172800 IN NS a.iana-servers.net. xn--gecrj9c. 172800 IN NS a0.cctld.afilias-nst.info. xn--h2brj9c. 172800 IN NS a0.cctld.afilias-nst.info. xn--hgbk6aj7f53bba. 172800 IN NS a.iana-servers.net. xn--hlcj6aya9esc7a. 172800 IN NS a.iana-servers.net. xn--j6w193g. 172800 IN NS b.dns.tw. xn--jxalpdlp. 172800 IN NS a.iana-servers.net. xn--kgbechtv. 172800 IN NS a.iana-servers.net. xn--kprw13d. 172800 IN NS d.dns.tw. xn--kpry57d. 172800 IN NS d.dns.tw. xn--lgbbat1ad8j. 172800 IN NS idn1.nic.dz. xn--mgbaam7a8h. 172800 IN NS ns1.aedns.ae. xn--mgbayh7gpa. 172800 IN NS jo.cctld.authdns.ripe.net. xn--mgbbh1a71e. 172800 IN NS a0.cctld.afilias-nst.info. xn--mgbc0a9azcg. 172800 IN NS ns2.nic.fr. xn--mgberp4a5d4ar. 172800 IN NS ns1.isu.net.sa. xn--o3cw4h. 172800 IN NS ns.thnic.net. xn--ogbpf8fl. 172800 IN NS sy.cctld.authdns.ripe.net. xn--p1ai. 172800 IN NS d.dns.ripn.net. xn--pgbs0dh. 172800 IN NS ns2.nic.fr. xn--s9brj9c. 172800 IN NS a0.cctld.afilias-nst.info. xn--wgbh1c. 172800 IN NS ns1.dotmasr.eg. xn--wgbl6a. 172800 IN NS qa.cctld.authdns.ripe.net. xn--xkc2al3hye2a. 172800 IN NS lk.communitydns.net. xn--xkc2dl3a5ee0h. 172800 IN NS a0.cctld.afilias-nst.info. xn--yfro4i67o. 172800 IN NS ns2.cuhk.edu.hk. xn--ygbi2ammx. 172800 IN NS idn.pnina.ps. xn--zckzah. 172800 IN NS a.iana-servers.net. xxx. 172800 IN NS a0.xxx.afilias-nst.info.
In article <95F7DF59-052D-43BA-869F-289DF915C62E@arbor.net> you write:
On Mar 10, 2012, at 7:02 PM, Robert E. Seastrom wrote:
there are four gtlds Aren't there actually seven? Including the new IDN TLDs, there are now 60.
well .... there are the legacy (pre-2000) set. there are the seven arising from the 7-10 proposal from WG-C*, aka the "2000 round**", of which three are "sponsored" (restrictions on registration policies) and four were "generic" (no such restrictions, price caps), all of which operate in some form or another at present. there are the set arising from the 2004 round***, all of which nominally are "sponsored", which now includes .xxx, but does not yet include .post (501(c)(3) (choice-of-contracting-or-memoing with a treaty organization problem), so about two dozen. there are the IDN (ascii encoded representations of unicode) delegations arising from the IDN ccTLD Fast-Track program, which share the no-or-significiantly-different-contract property of the delegations made for most iso3166 code points. to refer to these as "generic" is both reasonable, and misleading. the underlying issue is whether the operator has repurposed the original ASCII, or subsequent IDN delegations, as more similar to the CNOBI**** set of registries on a registration policy basis, making the delegation "generic", but without a CNOBI-like contract with ICANN, or not. examples of repurposed ccTLDs are nu, cc, me, us, ... the location of registries is quite distinct from the location of name server constellations, with the former being mono- or dual-sited, and operated by the delegee or single (there are exceptions) contractor, and the latter being multi-sited, and operated by multiple parties. a related issue, the subject of v6 evangelism, is the availability of redundant transit, which under the current ICANN DAG, appears to me to preclude registry siting in venues lacking redundant native v6 transit in Q12013, limiting data centers in Africa and South Asia. cheers, -e * member, WG-C. ** contributor to one or more successful 2000 registry inits. *** contributor to one or more successful 2004 registry inits. **** CNOBI == COM/NET/ORG/BIZ/INFO -- a single business model.
On Mar 10, 2012, at 7:24 AM, John Levine wrote:
In article <95F7DF59-052D-43BA-869F-289DF915C62E@arbor.net> you write:
On Mar 10, 2012, at 7:02 PM, Robert E. Seastrom wrote:
there are four gtlds Aren't there actually seven?
Including the new IDN TLDs, there are now 60.
The IDN TLDs (to date, with the exception of the test IDN TLDs) are more properly considered ccTLDs as they are the localized version of country names. Also, one could make a distinction between sponsored TLDs and generic TLDs, but that's probably splitting hairs. Regards, -drc
The IDN TLDs (to date, with the exception of the test IDN TLDs) are more properly considered ccTLDs as they are the localized version of country names.
Good point.
Also, one could make a distinction between sponsored TLDs and generic TLDs, but that's probably splitting hairs.
I suppose, but they all have similar registry and registrar agreements with ICANN, which is what makes them different from ccTLDs. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
Also, one could make a distinction between sponsored TLDs and generic TLDs, but that's probably splitting hairs.
I suppose, but they all have similar registry and registrar agreements with ICANN, which is what makes them different from ccTLDs.
at present there are almost as many substantively distinct contracts as there are post-legacy, non-country-code (ASCII and IDN) registries. there are similarities, but there are also distinct differences in registration policy, price caps, and cross ownership. imo, the hair to split is the business models of the operators: there is one business model characterized by $6 FCFS as modified by the UDRP. this business model is common to the VGRS properties, the Afilias and the NeuStar properties. there is another business model characterized by greater restrictions on registrations. this business model is common to the CORE properties and the NCUA property. ppc density in the string space about {google, microsoft, walmart, ibm, vodafone, bank of america, general electric, apple, wells fargo, at&t}* common marks in a namespace is one distinguishing characteristic. another hair to split is the operational practice of ccTLD registries. many lack "nexus" requirements, and share the ppc density of the $6/FCFS/UDRP business model, and quite a few have few registrations other than foreign jurisdiction trademarks. -e * forbes top ten list of 6/15/11.
Since there was a question about this, some numbers: Serial: 2012031001 Statistics ========== Number of root servers: 13 Roots with IPv6 glue: 9 Number of gTLDs: 22 Number of ccTLDs: 249 Number of IDN TLDs: 42 Total number of TLDs: 313 Number of IPv4 hosts: 1176 Number of IPv4 addresses: 1145 Number of IPv6 hosts: 427 Number of IPv6 addresses: 412 TLDs with IPv6 glue: 258 Total name server hosts: 1177 Total NS addresses: 1557 Number of DS records: 141 Number of TLDs with DS: 85 Enjoy, Doug -- If you're never wrong, you're not trying hard enough
Thanks for sharing interesting data. Was wondering you have map of g TLD server locations? Something like that of root servers? (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On Mar 11, 2012 4:44 AM, "Doug Barton" <dougb@dougbarton.us> wrote:
Since there was a question about this, some numbers:
Serial: 2012031001
Statistics ========== Number of root servers: 13 Roots with IPv6 glue: 9
Number of gTLDs: 22 Number of ccTLDs: 249 Number of IDN TLDs: 42 Total number of TLDs: 313
Number of IPv4 hosts: 1176 Number of IPv4 addresses: 1145
Number of IPv6 hosts: 427 Number of IPv6 addresses: 412 TLDs with IPv6 glue: 258
Total name server hosts: 1177 Total NS addresses: 1557
Number of DS records: 141 Number of TLDs with DS: 85
Enjoy,
Doug
-- If you're never wrong, you're not trying hard enough
Anurag, On Mar 11, 2012, at 9:11 AM, Anurag Bhatia wrote:
Thanks for sharing interesting data. Was wondering you have map of g TLD server locations? Something like that of root servers?
You would probably need to ask the operators of the gTLDs. As they are (generally) commercial services, whether they publish the locations of their servers is a business decision that they would each independently make. Regards, -drc
Anurag,
On Mar 11, 2012, at 9:11 AM, Anurag Bhatia wrote:
Thanks for sharing interesting data. Was wondering you have map of g TLD server locations? Something like that of root servers?
You would probably need to ask the operators of the gTLDs. As they are (generally) commercial services, whether they publish the locations of
On Sunday, 11 March 2012, David Conrad <drc@virtualized.org> wrote: their servers is a business decision that they would each independently make.
Regards, -drc
Correct, location of the .uk servers aren't published as they are treated as part of national infrastructure and protected as such -- Martin Oxford uk -- -- Martin Hepworth Oxford, UK
Some nice info here, too: http://bgp.he.net/report/dns Frank -----Original Message----- From: Doug Barton [mailto:dougb@dougbarton.us] Sent: Saturday, March 10, 2012 5:14 PM Cc: APNIC Mailing List; nanog@nanog.org Subject: root zone stats Since there was a question about this, some numbers: Serial: 2012031001 Statistics ========== Number of root servers: 13 Roots with IPv6 glue: 9 Number of gTLDs: 22 Number of ccTLDs: 249 Number of IDN TLDs: 42 Total number of TLDs: 313 Number of IPv4 hosts: 1176 Number of IPv4 addresses: 1145 Number of IPv6 hosts: 427 Number of IPv6 addresses: 412 TLDs with IPv6 glue: 258 Total name server hosts: 1177 Total NS addresses: 1557 Number of DS records: 141 Number of TLDs with DS: 85 Enjoy, Doug -- If you're never wrong, you're not trying hard enough
On Sun, 11 Mar 2012, Frank Bulk wrote:
Some nice info here, too: http://bgp.he.net/report/dns
Nice, but... not 100% up to date? .cw seems to be missing. -- Marco
Frank
-----Original Message----- From: Doug Barton [mailto:dougb@dougbarton.us] Sent: Saturday, March 10, 2012 5:14 PM Cc: APNIC Mailing List; nanog@nanog.org Subject: root zone stats
Since there was a question about this, some numbers:
Serial: 2012031001
Statistics ========== Number of root servers: 13 Roots with IPv6 glue: 9
Number of gTLDs: 22 Number of ccTLDs: 249 Number of IDN TLDs: 42 Total number of TLDs: 313
Number of IPv4 hosts: 1176 Number of IPv4 addresses: 1145
Number of IPv6 hosts: 427 Number of IPv6 addresses: 412 TLDs with IPv6 glue: 258
Total name server hosts: 1177 Total NS addresses: 1557
Number of DS records: 141 Number of TLDs with DS: 85
Enjoy,
Doug
-- If you're never wrong, you're not trying hard enough
On Mon, 12 Mar 2012, Marco Davids (Prive) wrote:
Some nice info here, too: http://bgp.he.net/report/dns
.cw seems to be missing.
Oops, it isn't... it's just not wehere I expected it. -- Marco
Shouldn't "eh" be Canada and not Western Sahara? -Hammer- "I was a normal American nerd" -Jack Herer On 3/12/2012 3:10 PM, Marco Davids (Prive) wrote:
On Mon, 12 Mar 2012, Marco Davids (Prive) wrote:
Some nice info here, too: http://bgp.he.net/report/dns
.cw seems to be missing.
Oops, it isn't... it's just not wehere I expected it.
-- Marco
On Mar 10, 2012, at 1:28 AM, Anurag Bhatia wrote:
Can someone share if there's huge difference in . root servers Vs gTLD servers?
Yes, there is a huge difference. For one thing (and ignoring the quantity of data), the operations of a gTLD's name servers is managed by a single entity (e.g., for .COM, VeriSign). The root servers are independently managed by 12 different organizations with no central management.
I understand that root only hold all TLD's - cc and gTLD delegation that would be few hundred TLDs delegation while gTLDs hold lot of domain names but if one country has root, what prevents having gTLD also?
I'd imagine business/economic rationales. From the perspective of a gTLD operator, what's the business justification for deploying non-trivial opex/capex? Root server deployments are less driven by economics and are more political in nature. Regards, -drc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mar 9, 2012, at 11:05 PM, Graham Beneke wrote:
There appear to be no anycast instances of the gTLD servers in Africa either.
That's not the case. .ORG, for example, is hosted in Cape Town and Cairo, and we host more than a hundred ccTLDs in those two locations as well as Maputo, Dar es Salaam, Johannesburg, and Nairobi. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJPW56jAAoJEG+kcEsoi3+H3tsP+QFick6sCDyZUrfzMt80zNs6 GnPiH3bjqU/vTu9aGN/t+R2C01NjnOCOzVYkQE18EVsGA1jluEGaD6+gu05v83Cf qQby5W1EekwNuxdnP/avhmJwnz9+4Kgg6dNVePC6uwNmjKd85ppE5AErKq5RSj6X WjKoiN9ILV/P8SHtdFA8NcqaAC8AtTcB0JUUAw+rCBNsmRZv2S6zbQ+wnuExWaU9 gEeAYAOEsufb+xNydKPhCFsjwCKH5cCuG8VO8QYR50XvpErvFiemlEHcCqSi+3o3 v1jlL8tSQWp/x9MVDZWvy6h6s8GxOoOJkN5n+i1YHCw5ofTHR4zW4OuY9QWkrbKA hxSzXUzw8m0btKn4MMrMpV8yZecBqn1dIbhiCYud26G71azyFX+PkLKTT5GtMUdN y2MVmdHwnDIantJbKWOeXltw//8xB0GdB5S09jcKCOhgrWaqYW1fsytcieRi0/AK txDvob8fXHt6Fi30X4SHD2Q1NylM2mySgOYgx3aT2G9ZEimZE7xR3JwVVzLRfmXn d7InkGZEj2ziZD4QM4UHWW35FcYkvmzYcVugcBBoooD8UGwAwTxpXG07K9U5hdCG oA0F3JQweGqXp+C2ECKBSOjL7vSnrHoX9jPNAmMRsN91EuKIWcY3ReYl3e36ZJPX NCcBAxuXkxhgBG1VsSO3 =Um6m -----END PGP SIGNATURE-----
Thanks for info Mr Bill. What about India? Do you see any gTLD instances in India? On Sun, Mar 11, 2012 at 12:04 AM, Bill Woodcock <woody@pch.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Mar 9, 2012, at 11:05 PM, Graham Beneke wrote:
There appear to be no anycast instances of the gTLD servers in Africa either.
That's not the case. .ORG, for example, is hosted in Cape Town and Cairo, and we host more than a hundred ccTLDs in those two locations as well as Maputo, Dar es Salaam, Johannesburg, and Nairobi.
-Bill
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJPW56jAAoJEG+kcEsoi3+H3tsP+QFick6sCDyZUrfzMt80zNs6 GnPiH3bjqU/vTu9aGN/t+R2C01NjnOCOzVYkQE18EVsGA1jluEGaD6+gu05v83Cf qQby5W1EekwNuxdnP/avhmJwnz9+4Kgg6dNVePC6uwNmjKd85ppE5AErKq5RSj6X WjKoiN9ILV/P8SHtdFA8NcqaAC8AtTcB0JUUAw+rCBNsmRZv2S6zbQ+wnuExWaU9 gEeAYAOEsufb+xNydKPhCFsjwCKH5cCuG8VO8QYR50XvpErvFiemlEHcCqSi+3o3 v1jlL8tSQWp/x9MVDZWvy6h6s8GxOoOJkN5n+i1YHCw5ofTHR4zW4OuY9QWkrbKA hxSzXUzw8m0btKn4MMrMpV8yZecBqn1dIbhiCYud26G71azyFX+PkLKTT5GtMUdN y2MVmdHwnDIantJbKWOeXltw//8xB0GdB5S09jcKCOhgrWaqYW1fsytcieRi0/AK txDvob8fXHt6Fi30X4SHD2Q1NylM2mySgOYgx3aT2G9ZEimZE7xR3JwVVzLRfmXn d7InkGZEj2ziZD4QM4UHWW35FcYkvmzYcVugcBBoooD8UGwAwTxpXG07K9U5hdCG oA0F3JQweGqXp+C2ECKBSOjL7vSnrHoX9jPNAmMRsN91EuKIWcY3ReYl3e36ZJPX NCcBAxuXkxhgBG1VsSO3 =Um6m -----END PGP SIGNATURE-----
_______________________________________________ apnic-talk mailing list apnic-talk@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-talk
-- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com
On Mar 9, 2012, at 10:19 PM, Anurag Bhatia wrote:
I can see India has 3 root servers hosting root zone - i, j & k in India which is good. So we can resolve the root zone i.e dot within India.
One correction to that; F has been operating in India from NIXI Chennai's PoP since 2005. The reason you may not see it from your location in India is that it's a local node, so we advertise F's prefixes with the NO_EXPORT community string to limit it's reach to networks directly connected to the local IX/routeserver @NIXI Chennai. And even with that restriction as noted at APNIC 33 in Dehli, the node is one of our (F's) busiest in Asia... -Peter -- [ plosher@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
Thanks for info Peter I missed that because firstly no routes from major Indian backbones and second it is not even mentioned on official site of root servers - http://www.root-servers.org under F root. On Sun, Mar 11, 2012 at 4:27 PM, Peter Losher <plosher@isc.org> wrote:
On Mar 9, 2012, at 10:19 PM, Anurag Bhatia wrote:
I can see India has 3 root servers hosting root zone - i, j & k in India which is good. So we can resolve the root zone i.e dot within India.
One correction to that; F has been operating in India from NIXI Chennai's PoP since 2005. The reason you may not see it from your location in India is that it's a local node, so we advertise F's prefixes with the NO_EXPORT community string to limit it's reach to networks directly connected to the local IX/routeserver @NIXI Chennai.
And even with that restriction as noted at APNIC 33 in Dehli, the node is one of our (F's) busiest in Asia...
-Peter -- [ plosher@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
-- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com
On Mar 11, 2012, at 4:01 AM, Anurag Bhatia wrote:
Thanks for info Peter
I missed that because firstly no routes from major Indian backbones
I can assure you that we get a good chunk of traffic from at least one of the "major Indian Backbones". The Chennai PoP is smaller than NIXI's other locations in Mumbai/Dehli/Kolkata, but it has a couple of the major players...
and second it is not even mentioned on official site of root servers - http://www.root-servers.org under F root.
Umm, but it is... search for "Chennai, IN" and also look the "F" bubble on Chennai on the Google Map that is on the page. Best Wishes - Peter -- [ plosher@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
Oops Almost missed that. Sorry about that. Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily. On Sun, Mar 11, 2012 at 4:37 PM, Peter Losher <plosher@isc.org> wrote:
On Mar 11, 2012, at 4:01 AM, Anurag Bhatia wrote:
Thanks for info Peter
I missed that because firstly no routes from major Indian backbones
I can assure you that we get a good chunk of traffic from at least one of the "major Indian Backbones". The Chennai PoP is smaller than NIXI's other locations in Mumbai/Dehli/Kolkata, but it has a couple of the major players...
and second it is not even mentioned on official site of root servers - http://www.root-servers.org under F root.
Umm, but it is... search for "Chennai, IN" and also look the "F" bubble on Chennai on the Google Map that is on the page.
Best Wishes - Peter -- [ plosher@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
-- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com
On Mar 11, 2012, at 4:11 AM, Anurag Bhatia wrote:
Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily.
You would have to ask Verisign as operators of the com/net gTLD servers and Afilias for .org about their DNS deployments. I can only speak for ISC as we operate F.ROOT-SERVERS.NET. Best Wishes - Peter -- [ plosher@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
As J is already there in India which is operated by Verisign, I don't think it's difficult to add .com & .net by Verisign. Just talk to them. Regards, Che-Hoo On 11 Mar, 2012, at 7:27 PM, Peter Losher wrote:
On Mar 11, 2012, at 4:11 AM, Anurag Bhatia wrote:
Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily.
You would have to ask Verisign as operators of the com/net gTLD servers and Afilias for .org about their DNS deployments. I can only speak for ISC as we operate F.ROOT-SERVERS.NET.
Best Wishes - Peter -- [ plosher@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
Just looked at j root in detail. Unfortunately not much of traffic is going to J root. BSNL along with its main upstream providers Tata & Airtel - all picking outside routes. Tata AS4755 is taking directly to AS6453 while AS6453 is passing to NTT in London which is next taking back to Japan and then going to HK anycasted node (yeah head shake routing!). Here's a view: traceroute to j.gtld-servers.net (192.48.79.30), 30 hops max, 60 byte packets 1 router.local (192.168.1.1) [AS8151/AS28513] 1.180 ms 1.621 ms 2.121 ms 2 117.207.48.1 (117.207.48.1) [AS9829] 26.935 ms 29.328 ms 31.956 ms 3 218.248.173.46 (218.248.173.46) [AS9829] 34.393 ms 37.093 ms * 4 115.114.57.165.static-Mumbai.vsnl.net.in<http://115.114.57.165.static-mumbai.vsnl.net.in/> (115.114.57.165) [AS4755] 74.623 ms 78.281 ms 82.352 ms 5 if-0-100.tcore2.MLV-Mumbai.as6453.net (180.87.39.25) [*] 299.987 ms 300.397 ms 314.175 ms 6 if-6-2.tcore1.L78-London.as6453.net (80.231.130.5) [AS6453] 314.573 ms 264.576 ms 261.030 ms 7 Vlan704.icore1.LDN-London.as6453.net<http://vlan704.icore1.ldn-london.as6453.net/> (80.231.130.10) [AS6453] 279.896 ms 280.312 ms * 8 Vlan522.icore1.LDN-London.as6453.net<http://vlan522.icore1.ldn-london.as6453.net/> (195.219.83.22) [AS6453] 333.651 ms 326.233 ms 330.307 ms 9 ae-4.r23.londen03.uk.bb.gin.ntt.net (129.250.5.40) [AS2914] 323.084 ms 324.204 ms 329.300 ms 10 as-0.r22.osakjp01.jp.bb.gin.ntt.net (129.250.5.35) [AS2914] 457.845 ms 459.011 ms 456.842 ms 11 as-0.r20.newthk02.hk.bb.gin.ntt.net (129.250.2.7) [AS2914] 495.869 ms 495.615 ms 496.840 ms 12 ae-1.r02.chwahk02.hk.bb.gin.ntt.net (129.250.3.131) [AS2914] 476.471 ms 478.525 ms 478.104 ms 13 * * * 14 * * * 15 * * * *Router:* gin-mlv-core1 *Site:* IN, Mumbai - MLV, VSNL *Command:* show ip bgp 192.48.79.30 BGP routing table entry for *192.48.79.0/24* Bestpath Modifiers: deterministic-med Paths: (3 available, best #2) Multipath: eBGP 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from mlv-tcore1. (66.110.10.202) Origin IGP, valid, internal Community: Originator: ldn-icore1. 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from cxr-tcore1. (66.110.10.113) Origin IGP, valid, internal, best Community: Originator: ldn-icore1. 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from mlv-tcore2. (66.110.10.215) Origin IGP, valid, internal Community: Originator: ldn-icore1. Path via NTT in all cases. So Mumbai - London - Japan - HongKong. Very likely because of same old problem I mentioned - Tata peers with NTT in London but not Japan. anurag@laptop:~$ dig j.gtld-servers.net a +short 192.48.79.30 anurag@laptop:~$ awhois 192.48.79.30 AS | IP | BGP Prefix | CC | AS Name 36631 | 192.48.79.30 | 192.48.79.0/24 | US | ZGTLD - VeriSign Global Registry Services http://bgp.he.net/AS36631#_peers And situation for Airtel isn't better at all for J root. Instead of picking NTT, they are using Packnet/AsiaNetcom because Packnet is likely a client of Hurricane Electric and Airtel peers with HE. Mon Mar 12 14:22:49 GMT+05:30 2012 traceroute 192.48.79.30 Type escape sequence to abort. Tracing the route to j.gtld-servers.net (192.48.79.30) 1 59.145.6.149 [MPLS: Label 800 Exp 0] 288 msec 59.145.6.145 [MPLS: Label 800 Exp 0] 284 msec 59.145.0.181 [MPLS: Label 1668 Exp 0] 260 msec 2 202.56.223.50 [MPLS: Label 308480 Exp 0] 256 msec 256 msec 202.56.223.205 [MPLS: Label 311696 Exp 0] 276 msec 3 182.79.220.198 [MPLS: Label 1795 Exp 0] 276 msec 276 msec 182.79.252.161 [MPLS: Label 1795 Exp 0] 272 msec 4 AES-Static-122.36.144.59.airtel.in<http://aes-static-122.36.144.59.airtel.in/> (59.144.36.122) 272 msec 272 msec 288 msec 5 he.net.coresite.com (206.223.143.122) 288 msec 292 msec 272 msec 6 10gigabitethernet2-1.core1.lax1.he.net (72.52.92.121) [AS 6939] 272 msec 276 msec 288 msec 7 pacnet.10gigabitethernet2-3.core1.lax1.he.net (216.218.223.206) [AS 6939] 288 msec 288 msec 272 msec 8 te0-1-0-0.wr1.nrt0.asianetcom.net (61.14.157.89) [AS 10026] 264 msec 264 msec 284 msec 9 te0-0-4-0.wr2.nrt0.asianetcom.net (61.14.157.14) [AS 10026] [MPLS: Label 16191 Exp 0] 288 msec 292 msec 276 msec 10 te0-0-0-0.wr2.osa0.asianetcom.net (61.14.157.2) [AS 10026] [MPLS: Label 16002 Exp 0] 276 msec 300 msec 292 msec 11 te0-0-4-0.wr1.osa0.asianetcom.net (61.14.157.21) [AS 10026] 292 msec 292 msec 276 msec 12 te0-1-0-0.wr1.hkg0.asianetcom.net (61.14.157.57) [AS 10026] 272 msec 268 msec 288 msec 13 ge-4-1-0-0.cr4.hkg3.asianetcom.net (61.14.157.142) [AS 10026] 284 msec 288 msec 264 msec 14 te3-2.gw1.hkg4.asianetcom.net (202.147.16.198) [AS 10026] 336 msec 264 msec 284 msec 15 VNB-0025.gw1.hkg4.asianetcom.net<http://vnb-0025.gw1.hkg4.asianetcom.net/> (203.192.137.78) [AS 10026] 284 msec 288 msec 268 msec 16 * * * Same problem applies on J gTLD server too. It might be having an instance in India but since no link to local ISPs or niXi...everyone hears J root in Hong Kong. Anyone from Verisign or Indian ISPs here for onlist or offlist comments? Again, I apologize for any wrong conclusions. I am still learning all this stuff. Please excuse my ignorance and correct me if you find something. Thanks On Sun, Mar 11, 2012 at 4:57 PM, Peter Losher <plosher@isc.org> wrote:
On Mar 11, 2012, at 4:11 AM, Anurag Bhatia wrote:
Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily.
You would have to ask Verisign as operators of the com/net gTLD servers and Afilias for .org about their DNS deployments. I can only speak for ISC as we operate F.ROOT-SERVERS.NET.
Best Wishes - Peter -- [ plosher@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
-- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com
J root should be j.root-servers.net (192.58.128.30). Che-Hoo On 12 Mar, 2012, at 5:09 PM, Anurag Bhatia wrote:
Just looked at j root in detail.
Unfortunately not much of traffic is going to J root. BSNL along with its main upstream providers Tata & Airtel - all picking outside routes. Tata AS4755 is taking directly to AS6453 while AS6453 is passing to NTT in London which is next taking back to Japan and then going to HK anycasted node (yeah head shake routing!).
Here's a view:
traceroute to j.gtld-servers.net (192.48.79.30), 30 hops max, 60 byte packets 1 router.local (192.168.1.1) [AS8151/AS28513] 1.180 ms 1.621 ms 2.121 ms 2 117.207.48.1 (117.207.48.1) [AS9829] 26.935 ms 29.328 ms 31.956 ms 3 218.248.173.46 (218.248.173.46) [AS9829] 34.393 ms 37.093 ms * 4 115.114.57.165.static-Mumbai.vsnl.net.in (115.114.57.165) [AS4755] 74.623 ms 78.281 ms 82.352 ms 5 if-0-100.tcore2.MLV-Mumbai.as6453.net (180.87.39.25) [*] 299.987 ms 300.397 ms 314.175 ms 6 if-6-2.tcore1.L78-London.as6453.net (80.231.130.5) [AS6453] 314.573 ms 264.576 ms 261.030 ms 7 Vlan704.icore1.LDN-London.as6453.net (80.231.130.10) [AS6453] 279.896 ms 280.312 ms * 8 Vlan522.icore1.LDN-London.as6453.net (195.219.83.22) [AS6453] 333.651 ms 326.233 ms 330.307 ms 9 ae-4.r23.londen03.uk.bb.gin.ntt.net (129.250.5.40) [AS2914] 323.084 ms 324.204 ms 329.300 ms 10 as-0.r22.osakjp01.jp.bb.gin.ntt.net (129.250.5.35) [AS2914] 457.845 ms 459.011 ms 456.842 ms 11 as-0.r20.newthk02.hk.bb.gin.ntt.net (129.250.2.7) [AS2914] 495.869 ms 495.615 ms 496.840 ms 12 ae-1.r02.chwahk02.hk.bb.gin.ntt.net (129.250.3.131) [AS2914] 476.471 ms 478.525 ms 478.104 ms 13 * * * 14 * * * 15 * * *
Router: gin-mlv-core1 Site: IN, Mumbai - MLV, VSNL Command: show ip bgp 192.48.79.30
BGP routing table entry for 192.48.79.0/24 Bestpath Modifiers: deterministic-med Paths: (3 available, best #2) Multipath: eBGP 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from mlv-tcore1. (66.110.10.202) Origin IGP, valid, internal Community: Originator: ldn-icore1. 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from cxr-tcore1. (66.110.10.113) Origin IGP, valid, internal, best Community: Originator: ldn-icore1. 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from mlv-tcore2. (66.110.10.215) Origin IGP, valid, internal Community: Originator: ldn-icore1.
Path via NTT in all cases.
So Mumbai - London - Japan - HongKong. Very likely because of same old problem I mentioned - Tata peers with NTT in London but not Japan.
anurag@laptop:~$ dig j.gtld-servers.net a +short 192.48.79.30
anurag@laptop:~$ awhois 192.48.79.30 AS | IP | BGP Prefix | CC | AS Name 36631 | 192.48.79.30 | 192.48.79.0/24 | US | ZGTLD - VeriSign Global Registry Services
http://bgp.he.net/AS36631#_peers
And situation for Airtel isn't better at all for J root. Instead of picking NTT, they are using Packnet/AsiaNetcom because Packnet is likely a client of Hurricane Electric and Airtel peers with HE.
Mon Mar 12 14:22:49 GMT+05:30 2012 traceroute 192.48.79.30
Type escape sequence to abort. Tracing the route to j.gtld-servers.net (192.48.79.30)
1 59.145.6.149 [MPLS: Label 800 Exp 0] 288 msec 59.145.6.145 [MPLS: Label 800 Exp 0] 284 msec 59.145.0.181 [MPLS: Label 1668 Exp 0] 260 msec 2 202.56.223.50 [MPLS: Label 308480 Exp 0] 256 msec 256 msec 202.56.223.205 [MPLS: Label 311696 Exp 0] 276 msec 3 182.79.220.198 [MPLS: Label 1795 Exp 0] 276 msec 276 msec 182.79.252.161 [MPLS: Label 1795 Exp 0] 272 msec 4 AES-Static-122.36.144.59.airtel.in (59.144.36.122) 272 msec 272 msec 288 msec 5 he.net.coresite.com (206.223.143.122) 288 msec 292 msec 272 msec 6 10gigabitethernet2-1.core1.lax1.he.net (72.52.92.121) [AS 6939] 272 msec 276 msec 288 msec 7 pacnet.10gigabitethernet2-3.core1.lax1.he.net (216.218.223.206) [AS 6939] 288 msec 288 msec 272 msec 8 te0-1-0-0.wr1.nrt0.asianetcom.net (61.14.157.89) [AS 10026] 264 msec 264 msec 284 msec 9 te0-0-4-0.wr2.nrt0.asianetcom.net (61.14.157.14) [AS 10026] [MPLS: Label 16191 Exp 0] 288 msec 292 msec 276 msec 10 te0-0-0-0.wr2.osa0.asianetcom.net (61.14.157.2) [AS 10026] [MPLS: Label 16002 Exp 0] 276 msec 300 msec 292 msec 11 te0-0-4-0.wr1.osa0.asianetcom.net (61.14.157.21) [AS 10026] 292 msec 292 msec 276 msec 12 te0-1-0-0.wr1.hkg0.asianetcom.net (61.14.157.57) [AS 10026] 272 msec 268 msec 288 msec 13 ge-4-1-0-0.cr4.hkg3.asianetcom.net (61.14.157.142) [AS 10026] 284 msec 288 msec 264 msec 14 te3-2.gw1.hkg4.asianetcom.net (202.147.16.198) [AS 10026] 336 msec 264 msec 284 msec 15 VNB-0025.gw1.hkg4.asianetcom.net (203.192.137.78) [AS 10026] 284 msec 288 msec 268 msec 16 * * *
Same problem applies on J gTLD server too. It might be having an instance in India but since no link to local ISPs or niXi...everyone hears J root in Hong Kong.
Anyone from Verisign or Indian ISPs here for onlist or offlist comments?
Again, I apologize for any wrong conclusions. I am still learning all this stuff. Please excuse my ignorance and correct me if you find something.
Thanks
On Sun, Mar 11, 2012 at 4:57 PM, Peter Losher <plosher@isc.org> wrote: On Mar 11, 2012, at 4:11 AM, Anurag Bhatia wrote:
Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily.
You would have to ask Verisign as operators of the com/net gTLD servers and Afilias for .org about their DNS deployments. I can only speak for ISC as we operate F.ROOT-SERVERS.NET.
Best Wishes - Peter -- [ plosher@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
--
Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network!
Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com
_______________________________________________ apnic-talk mailing list apnic-talk@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-talk
Thanks everyone for your replies. I found those really insightful (specially the offlist ones) ;) I got fairly decent image on why things are looking so bad here. On Mon, Mar 12, 2012 at 3:15 PM, Che-Hoo CHENG <chcheng@ieee.org> wrote:
J root should be j.root-servers.net (192.58.128.30).
Che-Hoo
On 12 Mar, 2012, at 5:09 PM, Anurag Bhatia wrote:
Just looked at j root in detail.
Unfortunately not much of traffic is going to J root. BSNL along with its main upstream providers Tata & Airtel - all picking outside routes. Tata AS4755 is taking directly to AS6453 while AS6453 is passing to NTT in London which is next taking back to Japan and then going to HK anycasted node (yeah head shake routing!).
Here's a view:
traceroute to j.gtld-servers.net (192.48.79.30), 30 hops max, 60 byte packets 1 router.local (192.168.1.1) [AS8151/AS28513] 1.180 ms 1.621 ms 2.121 ms 2 117.207.48.1 (117.207.48.1) [AS9829] 26.935 ms 29.328 ms 31.956 ms 3 218.248.173.46 (218.248.173.46) [AS9829] 34.393 ms 37.093 ms * 4 115.114.57.165.static-Mumbai.vsnl.net.in<http://115.114.57.165.static-mumbai.vsnl.net.in/> (115.114.57.165) [AS4755] 74.623 ms 78.281 ms 82.352 ms 5 if-0-100.tcore2.MLV-Mumbai.as6453.net (180.87.39.25) [*] 299.987 ms 300.397 ms 314.175 ms 6 if-6-2.tcore1.L78-London.as6453.net (80.231.130.5) [AS6453] 314.573 ms 264.576 ms 261.030 ms 7 Vlan704.icore1.LDN-London.as6453.net<http://vlan704.icore1.ldn-london.as6453.net/> (80.231.130.10) [AS6453] 279.896 ms 280.312 ms * 8 Vlan522.icore1.LDN-London.as6453.net<http://vlan522.icore1.ldn-london.as6453.net/> (195.219.83.22) [AS6453] 333.651 ms 326.233 ms 330.307 ms 9 ae-4.r23.londen03.uk.bb.gin.ntt.net (129.250.5.40) [AS2914] 323.084 ms 324.204 ms 329.300 ms 10 as-0.r22.osakjp01.jp.bb.gin.ntt.net (129.250.5.35) [AS2914] 457.845 ms 459.011 ms 456.842 ms 11 as-0.r20.newthk02.hk.bb.gin.ntt.net (129.250.2.7) [AS2914] 495.869 ms 495.615 ms 496.840 ms 12 ae-1.r02.chwahk02.hk.bb.gin.ntt.net (129.250.3.131) [AS2914] 476.471 ms 478.525 ms 478.104 ms 13 * * * 14 * * * 15 * * *
*Router:* gin-mlv-core1 *Site:* IN, Mumbai - MLV, VSNL *Command:* show ip bgp 192.48.79.30
BGP routing table entry for *192.48.79.0/24* Bestpath Modifiers: deterministic-med Paths: (3 available, best #2) Multipath: eBGP 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from mlv-tcore1. (66.110.10.202) Origin IGP, valid, internal Community: Originator: ldn-icore1. 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from cxr-tcore1. (66.110.10.113) Origin IGP, valid, internal, best Community: Originator: ldn-icore1. 2914 36631 36631, (aggregated by 36631 203.131.245.40) ldn-icore1. (metric 2991) from mlv-tcore2. (66.110.10.215) Origin IGP, valid, internal Community: Originator: ldn-icore1.
Path via NTT in all cases.
So Mumbai - London - Japan - HongKong. Very likely because of same old problem I mentioned - Tata peers with NTT in London but not Japan.
anurag@laptop:~$ dig j.gtld-servers.net a +short 192.48.79.30
anurag@laptop:~$ awhois 192.48.79.30 AS | IP | BGP Prefix | CC | AS Name 36631 | 192.48.79.30 | 192.48.79.0/24 | US | ZGTLD - VeriSign Global Registry Services
http://bgp.he.net/AS36631#_peers
And situation for Airtel isn't better at all for J root. Instead of picking NTT, they are using Packnet/AsiaNetcom because Packnet is likely a client of Hurricane Electric and Airtel peers with HE.
Mon Mar 12 14:22:49 GMT+05:30 2012 traceroute 192.48.79.30
Type escape sequence to abort. Tracing the route to j.gtld-servers.net (192.48.79.30)
1 59.145.6.149 [MPLS: Label 800 Exp 0] 288 msec 59.145.6.145 [MPLS: Label 800 Exp 0] 284 msec 59.145.0.181 [MPLS: Label 1668 Exp 0] 260 msec 2 202.56.223.50 [MPLS: Label 308480 Exp 0] 256 msec 256 msec 202.56.223.205 [MPLS: Label 311696 Exp 0] 276 msec 3 182.79.220.198 [MPLS: Label 1795 Exp 0] 276 msec 276 msec 182.79.252.161 [MPLS: Label 1795 Exp 0] 272 msec 4 AES-Static-122.36.144.59.airtel.in<http://aes-static-122.36.144.59.airtel.in/> (59.144.36.122) 272 msec 272 msec 288 msec 5 he.net.coresite.com (206.223.143.122) 288 msec 292 msec 272 msec 6 10gigabitethernet2-1.core1.lax1.he.net (72.52.92.121) [AS 6939] 272 msec 276 msec 288 msec 7 pacnet.10gigabitethernet2-3.core1.lax1.he.net (216.218.223.206) [AS 6939] 288 msec 288 msec 272 msec 8 te0-1-0-0.wr1.nrt0.asianetcom.net (61.14.157.89) [AS 10026] 264 msec 264 msec 284 msec 9 te0-0-4-0.wr2.nrt0.asianetcom.net (61.14.157.14) [AS 10026] [MPLS: Label 16191 Exp 0] 288 msec 292 msec 276 msec 10 te0-0-0-0.wr2.osa0.asianetcom.net (61.14.157.2) [AS 10026] [MPLS: Label 16002 Exp 0] 276 msec 300 msec 292 msec 11 te0-0-4-0.wr1.osa0.asianetcom.net (61.14.157.21) [AS 10026] 292 msec 292 msec 276 msec 12 te0-1-0-0.wr1.hkg0.asianetcom.net (61.14.157.57) [AS 10026] 272 msec 268 msec 288 msec 13 ge-4-1-0-0.cr4.hkg3.asianetcom.net (61.14.157.142) [AS 10026] 284 msec 288 msec 264 msec 14 te3-2.gw1.hkg4.asianetcom.net (202.147.16.198) [AS 10026] 336 msec 264 msec 284 msec 15 VNB-0025.gw1.hkg4.asianetcom.net<http://vnb-0025.gw1.hkg4.asianetcom.net/> (203.192.137.78) [AS 10026] 284 msec 288 msec 268 msec 16 * * *
Same problem applies on J gTLD server too. It might be having an instance in India but since no link to local ISPs or niXi...everyone hears J root in Hong Kong.
Anyone from Verisign or Indian ISPs here for onlist or offlist comments?
Again, I apologize for any wrong conclusions. I am still learning all this stuff. Please excuse my ignorance and correct me if you find something.
Thanks
On Sun, Mar 11, 2012 at 4:57 PM, Peter Losher <plosher@isc.org> wrote:
On Mar 11, 2012, at 4:11 AM, Anurag Bhatia wrote:
Btw coming back to original question - can you put some light on gTLDs in India? Are there any instances? Just to clarify - with gTLD I am refering to .com/net/org primarily.
You would have to ask Verisign as operators of the com/net gTLD servers and Afilias for .org about their DNS deployments. I can only speak for ISC as we operate F.ROOT-SERVERS.NET.
Best Wishes - Peter -- [ plosher@isc.org | Senior Operations Architect | ISC | PGP E8048D08 ]
--
Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network!
Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com
_______________________________________________ apnic-talk mailing list apnic-talk@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-talk
-- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/11/2012 03:57 AM, Peter Losher wrote:
On Mar 9, 2012, at 10:19 PM, Anurag Bhatia wrote:
I can see India has 3 root servers hosting root zone - i, j & k in India which is good. So we can resolve the root zone i.e dot within India.
One correction to that; F has been operating in India from NIXI Chennai's PoP since 2005. The reason you may not see it from your location in India is that it's a local node, so we advertise F's prefixes with the NO_EXPORT community string to limit it's reach to networks directly connected to the local IX/routeserver @NIXI Chennai.
I see 192.5.5.0/24 less widely seen by the peers as opposed to 192.5.4.0/23 maybe as you mentioned the longer prefix (/24) should be visible to clients using local instance of f-root. Why? It would be bad to attract traffic from half way around the world to a local node as they are there to serve the local community. Just wondering how do the other root keepers manage that because reminds me of an outage (k-root related) sometime september or october time frame of 2010 that a /24 may have leak more widely than intended from a one of the local instances. I know off-topic here but what caught my interest is in "no_export" set for root server as the outage mentioned above came near the K-root local instance in India. regards, /virendra
And even with that restriction as noted at APNIC 33 in Dehli, the node is one of our (F's) busiest in Asia...
-Peter
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk9dM6QACgkQ3HuimOHfh+H61gD/VGHBJdphTPA1yOYUGr7nmouG UJwR3yL4WAPcgfpDh6oA/AvwWW7kqU00ghOVE+Xioejv2gKPBQDB18hHGrmEcxtY =RDVK -----END PGP SIGNATURE-----
participants (25)
-
-Hammer- -
Anurag Bhatia -
Bill Woodcock -
Che-Hoo CHENG -
David Conrad -
Dobbins, Roland -
Doug Barton -
Edward Lewis -
Eric Brunner-Williams -
Frank Bulk -
Frank Habicht -
Graham Beneke -
Joel jaeggli -
John Levine -
John R. Levine
-
Jonathan Lassoff -
Marco Davids (Prive) -
Martin Hepworth -
Owen DeLong -
Peter Losher -
Randy Bush -
Robert E. Seastrom -
Rubens Kuhl -
Suresh Ramasubramanian -
virendra rode