[bdNOG] .BD DNS Problem

Kabindra Shrestha kabindra at geeks.net.np
Thu Sep 8 18:03:36 BDT 2016


As Fakrul mentioned BTCL is in the process of adding PCH as secondary for .BD and if we see .BD zone file already carries PCH server as its NS

kabindra-shresthas-macbook-pro:~ kabindra$ dig @dns.bd bd ns +norec

; <<>> DiG 9.10.4-P2 <<>> @dns.bd bd ns +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17818
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bd.				IN	NS

;; ANSWER SECTION:
bd.			86400	IN	NS	dns.bd.
bd.			86400	IN	NS	bd-ns.anycast.pch.net.
bd.			86400	IN	NS	surma.btcl.net.bd.
bd.			86400	IN	NS	jamuna.btcl.net.bd.

;; ADDITIONAL SECTION:
dns.bd.			86400	IN	A	209.58.24.3
dns.bd.			86400	IN	AAAA	2407:5000:88:5::3
surma.btcl.net.bd.	8	IN	A	203.112.194.232
surma.btcl.net.bd.	8	IN	AAAA	2407:5000:88:4::232
jamuna.btcl.net.bd.	8	IN	A	203.112.194.231
jamuna.btcl.net.bd.	8	IN	AAAA	2407:5000:88:4::231

;; Query time: 555 msec
;; SERVER: 209.58.24.3#53(209.58.24.3)
;; WHEN: Thu Sep 08 17:41:47 NPT 2016
;; MSG SIZE  rcvd: 266

and you can notice the FLAGS on the above query includes 'AA' which tells us that its an authoritative data and if you query the parent zone for .BD which is root zone,  you will notice, FlAGS don't include 'AA' ( you can notice that on the below query )

kabindra-shresthas-macbook-pro:~ kabindra$ dig @a.root-servers.net bd ns +norec

; <<>> DiG 9.10.4-P2 <<>> @a.root-servers.net bd ns +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51335
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bd.				IN	NS

;; AUTHORITY SECTION:
bd.			172800	IN	NS	surma.btcl.net.bd.
bd.			172800	IN	NS	dns.bd.
bd.			172800	IN	NS	jamuna.btcl.net.bd.

;; ADDITIONAL SECTION:
surma.btcl.net.bd.	172800	IN	A	203.112.194.232
dns.bd.			172800	IN	A	209.58.24.3
jamuna.btcl.net.bd.	172800	IN	A	203.112.194.231

;; Query time: 186 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Thu Sep 08 17:41:19 NPT 2016
;; MSG SIZE  rcvd: 147


and technically authoritative data is always right and remember NS records in the parent are not authoritative, so the recursive resolvers must replace the delegation list with the list provided by the authoritative zone, which means PCH server is still going to get a fair amount of traffic for .BD, which is good :). We can say we added some resiliency even though its not official.

BUT there is another MAJOR problem other than POWER with .BD, which is, the ZONECUTs are not properly delegated. None of the zonecuts for .BD have a delegation configured on the .BD zone, which is really really bad and the only reason the zonecuts ( com.bd, net.bd etc... ) are working is due to they being served on the same NAME SERVER DAEMON.

 So you can say, if its working, how is that a problem,

- first and the most important, zone doesn't know about the zonecut, so technically, .BD doesn't even now that it has zonecuts or sub domains delegation ( zonecuts being served, is thanks to how the nameserver software behaves when zone and zonecut are served from the same daemon on the server )
- the bad part is, when you add another NS for .BD say like PCH which only has the zone (.BD) but not the zonecuts (COM.BD, NET.BD etc...) on it and since the .BD doesn't know about the zone cuts, the new NS will not know about the zone cuts and will give NXDOMAIN and thats what happening with PCH server. So any queries coming to PCH server for any of the zonecuts will result in NXDOMAIN, which is really bad and this has introduced another layer of failure in addition to the power problem.


kabindra-shresthas-macbook-pro:~ kabindra$ dig @bd-ns.anycast.pch.net com.bd

; <<>> DiG 9.10.4-P2 <<>> @bd-ns.anycast.pch.net com.bd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11447
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;com.bd.				IN	A

;; AUTHORITY SECTION:
bd.			86400	IN	SOA	dns.bd. root.dns.bd. 12 1800 3600 604800 86400

;; Query time: 168 msec
;; SERVER: 204.61.216.108#53(204.61.216.108)
;; WHEN: Thu Sep 08 17:22:21 NPT 2016
;; MSG SIZE  rcvd: 80


( This is not PCH specific problem. If you add any new NS which only carries .BD zone the result would be same and this configuration problem has to be fixed anyway )

How can we solve it?

- the zone cut needs to be properly delegated on the parent zone.

So the .BD zone file should contain something like,

com.bd.	IN	NS 	dns.bd.
		IN	NS	surma.btcl.net.bd.
		IN	NS	jamuna.btcl.net.bd.

net.bd.	IN	NS 	dns.bd.
		IN	NS	surma.btcl.net.bd.
		IN	NS	jamuna.btcl.net.bd.

( add glue record if it doesn't already exist or if necessary )

surma.btcl.net.bd.	IN	A	203.112.194.232
surma.btcl.net.bd.	IN	AAAA	2407:5000:88:4::232
jamuna.btcl.net.bd.	IN	A	203.112.194.231
jamuna.btcl.net.bd.	IN	AAAA	2407:5000:88:4::231


Do the same for any other zone cuts ( edu.bd, gov.bd etc... )

Please don't hesitate to ping me or even PCH team 'noc at pch.net' for any sort of help to fix this issue.

Thank you.

Regards,
Kabindra Shrestha

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.bdnog.org/pipermail/nog/attachments/20160908/a408a989/attachment.pgp>


More information about the nog mailing list