Someone recently reached out to me discussing DNS and as that person started taking deep dive in DNS, he came across the glue records. He asked me “Why not just use A records on a sub-zone with glue record at the parent zone”?
This was a fantastic question. I am going to document it in this post on why not. First and foremost let’s have a clear understanding of glue records.
Has been a while since I checked the status of root servers which are hosted at NIXI. The list as per their official member list stays the same i.e i root in Mumbai, K root in Noida and F root in Chennai.
show ip bgp neighbors 218.100.48.75 received-routes
There are 5 received routes from neighbor 218.100.48.75
Searching for matching routes, use ^C to quit...
Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST C:CONFED_EBGP D:DAMPED
E:EBGP H:HISTORY I:IBGP L:LOCAL M:MULTIPATH m:NOT-INSTALLED-MULTIPATH
S:SUPPRESSED F:FILTERED s:STALE
Prefix Next Hop MED LocPrf Weight Status
1 192.36.148.0/24 218.100.48.75 0 100 0 BE
AS_PATH: 8674 29216
2 194.58.198.0/24 218.100.48.75 0 100 0 BE
AS_PATH: 8674 56908
3 194.58.199.0/24 218.100.48.75 0 100 0 BE
AS_PATH: 8674 56908
4 194.146.106.0/24 218.100.48.75 0 100 0 BE
AS_PATH: 8674
5 194.146.107.0/24 218.100.48.75 0 100 0 BE
AS_PATH: 8674
A few days some folks in internet community noticed Cloudflare AS13335 announcing F root server’s routes covering prefix 192.5.5.0/24.
dig version.bind ch txt @f.root-servers.net pic.twitter.com/YLW7hqt170
— Tony Finch (@fanf) April 3, 2017
Above tweet shows that case is clearly not a mistake but rather some sort of arrangement between Cloudflare and ISC (which is responsible for F-root). There was another discussion on DNS-OARC mailing list here. From our bgp.he.net tool, one can analyse route propagation for F root’s AS3557.
Yesterday Google’s Bangladeshi website google.com.bd was hacked and this happened via DNS. It was reported on the bdNOG mailing list at morning in a thread started by Mr Omar Ali.
This clearly shows how authoritative DNS for “com.bd.” (which is same as bd. btw) was poisoned and was reflecting attackers authoritative DNS. Later Mr Farhad Ahmed posted a screenshot of google.com.bd showing hackers page:
Later Mr Sumon Ahmed mentioned that it happened because web frontend of .bd was compromised. This was an interesting hijack as attacker attacked the key infrastructure of the registry instead of Google or Facebook servers. It’s also a warm reminder of the way DNS depends on the hierarchal structure by design and at this stage, we need to focus on DNSSEC to add on the security to the current system. Lately .bd domain faced issues multiple time this year. I hope it will have a good stable time in the upcoming year. In terms of stability it is being backed by PCH anycast infrastructure but PCH’s DNS servers are just published in NS records of it’s existing auth servers, but not on the parent zone (which is root zone). Thus the point of failure remains and is yet to be fixed.
Talking about root DNS server’s anycast at APNIC42. YouTube here.
Just was looking around at EDNS support by Google. To find how it supports and how packet looks like I created a test NS records for dnstest.anuragbhatia.com pointing to one of test server (178.238.225.247). I wasn’t running any DNS server on the server. Just ran quick tcpdump.
At server end:
sudo tcpdump 'port 53 and dst 178.238.225.247' -nn -vvv -w sample.pcap
Then I forcefully triggered DNS queries via Google’s recursor using:**
Earlier this month Dyn started with it’s Indian PoP. I came across news from Dyn’s blog post. It’s very good to see first Amazon AWS and now Dyn in India. With a warm welcome to Dyn let’s look at their Indian deployment.
Dyn using AS33517 which seems to be having upstream from Tata-VSNL AS4755 and Airtel AS9498.
Dyn seems to be announcing 103.11.203.0/24 to both networks in Mumbai to transit. There are routes in global IPv4 routing table which show Tata & Airtel as transit for Dyn. It cannot be just a /24. I am sure there are more prefixes which are very likely locally announced. Since deployment is at Mumbai, let’s try to look at NIXI Mumbai for prefixes.We can see Tata AS4755 is using 218.100.48.85 and Airtel is using 218.100.48.86 from NIXI route server at Mumbai with simple “sh ip bgp sum” query. I tried taking entire table of Tata as well as of Airtel from NIXI route server but not able to get it beyond few thousand routes.
Few days back I noticed F root server (which is with ISC) brought it’s anycasted node in NIXI Chennai back live. They have taken that down as per my interaction with them over mailing list. My last post about F root coming back live was with guess work on who’s providing upstream. Today I spent sometime in finding who’s providing transit to that node. It is very important to note that most of these key infrastructure related nodes rely on peering for most of traffic but a transit in form of full table or default stays so that one can push packets to a route if it is not in table learnt from peering. In case of Indian deployment which was at NIXI Chennai - many ISPs were following regional routes clause of NIXI and were announcing just their regional routes (to ISC’s F root router) but quite a few of them (like BSNL) were still learning routes from one region and exporting them into their other region via their IGP. This brought case where my router (sitting on BSNL link) was getting a forward path to NIXI Chennai for F root but there was return path from F root to my system because BSNL wasn’t announcing Northern prefixes in Chennai based NIXI. As I noted earlier F root is back live in India and I am getting consistant and direct routes. It seems very much the case of addition of transit on that node. Today I was looking at global table dump and I came across some interesting routes which revealed who is probably the transit for ISC’s F root in India. :)
And finally ACN i.e “Advanced Computer Networks” exam next. Hopefully less to cram in this one and syllabus is pretty interesting.
Talking about networks - I am very happy to post this update. Finally F root server’s node in Chennai is back up!
Though ISC did not updated me about this development but anyways I can always assume they were busy in hitting head with India bureaucratic bodies. :)
If you are following my blog, you might have seen my past blog post about “Broken connectivity of F root server” due to NIXI’s routing policies. When I informed ISC (root server operator for F root) about it, they took down the Indian anycasting instance in order to work on fix.
One of my friend told me on error coming for http://www.musicindiaonline.com/ which was showing error that website is blocked as per DoT orders. I just checked it now and for now domain is not resolving at all! Quick analysis to see how site is blocked.
anurag@laptop:
$ dig musicindiaonline.com a ; «» DiG 9.8.1-P1 «» musicindiaonline.com a ;; global options: +cmd ;; Got answer: ;; -»HEADER«- opcode: QUERY, status: NOERROR, id: 23431 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;musicindiaonline.com. IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Nov 3 02:31:58 2012 ;; MSG SIZE rcvd: 38 anurag@laptop:$