[bdNOG] Issues with BD top level domain

Brian Candler brian at nsrc.org
Wed Mar 30 04:27:42 BDT 2016

Someone was asking me to help debug a problem with their domain, but 
this in turn showed that there are a bunch of problems with the .BD top 
level domain itself. Hopefully there is someone on this list who can 
look at them.

Firstly, here is the delegation at the root.

$ dig +norec @a.root-servers.net. bd. ns
bd.            172800    IN    NS    jamuna.btcl.net.bd.
bd.            172800    IN    NS    surma.btcl.net.bd.
bd.            172800    IN    NS    dns.bd.

jamuna.btcl.net.bd.    172800    IN    A
surma.btcl.net.bd.    172800    IN    A
*dns.bd.            172800    IN    A**

Now here is the information when you query one of these servers:

$ dig @ bd. ns
bd.            86400    IN    NS    dns2.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.
bd.            86400    IN    NS    dns.bd.

*dns.bd.            86400    IN    A**
**dns.bd.            86400    IN    AAAA    2407:5000:88:5::3**
*dns2.bd.        86400    IN    A

Problem 1: the IP address of dns.bd within the zone is different to the 
IP address of dns.bd in the glue records.

Problem 2: dns.bd does not respond on the IP address which is listed 
within the zone

$ dig +norec *@* bd. ns

; <<>> DiG 9.8.3-P1 <<>> +norec @ bd. ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, *status: **REFUSED*, id: 18221
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

Problem 3: although dns.bd *does* respond on the IPv6 address 
2407:5000:88:5::3, there is no glue for this in the root.

Problem 4: the bd zone lists two additional nameservers (dns2.bd and 
bd-ns.anycast.pch.net) which are not listed in the root

Problem 5: dns2.bd (on address does not respond to queries

$ dig @ dns2.bd. a

; <<>> DiG 9.8.3-P1 <<>> @ dns2.bd. a
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Since the data *inside* the zone is authoritative, and takes precedence 
over what is in the delegation from outside, this means that once 
someone has done a query for BD. they will (a) learn the wrong IP 
address for dns.bd, and (b) learn about dns2.bd which doesn't work at 
all - this will slow down queries for any .bd names going forward.

I tried some online DNS checkers and they didn't seem to be able to spot 
these problems. Doing it the old-fashioned manual way is still necessary 
it seems :-(

The way DNS fails over, things will still work more or less. But if you 
can make the delegation consistent with the content of the zone, things 
will work more reliably.


Brian Candler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.bdnog.org/pipermail/nog/attachments/20160329/2aca0390/attachment.html>

More information about the nog mailing list