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.

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.

This problem is unfortunately not unique to India. There appear to be no
anycast instances of the gTLD servers in Africa either.

really!?

Hello Randy

No idea about Africa but certainly none of gTLD servers in India.

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

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.

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.

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.

> 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.txt

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 <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)

Aren't there actually seven?

According to ICANN[1] there are "roughly two dozen gTLDs"

[1] http://newgtlds.icann.org/en/about

In article <95F7DF59-052D-43BA-869F-289DF915C62E@arbor.net> you write:

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:

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.

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

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

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.

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

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.

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