[bdNOG] .BD DNS Problem

Mon Sep 12 14:44:23 BDT 2016

> On Sep 9, 2016, at 2:32 PM, Brian Candler <brian at nsrc.org> wrote:
> 
> On 09/09/2016 08:50, Kabindra Shrestha wrote:
>> The analysis and solution was for .BD. As we know, for sub domains to work there needs to be a proper delegation which is missing in .BD
> 
> Yes, you are quite right - my apologies.
> 
> What confused me is when I got the correct answer here:
> 
> $ dig +norec @dns.bd. com.bd. ns
> ...
> ;; ANSWER SECTION:
> com.bd.            86400      IN         NS         dns.bd.
> com.bd.            86400      IN         NS  surma.btcl.net.bd.
> com.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.         2849       IN         A  203.112.194.232
> surma.btcl.net.bd.         2849       IN         AAAA  2407:5000:88:4::232
> jamuna.btcl.net.bd.        2849       IN         A  203.112.194.231
> jamuna.btcl.net.bd.        2849       IN         AAAA  2407:5000:88:4::231
> 
> In fact, what this shows is the NS records *within* the com.bd zone, which happens to be stored on the same nameserver; this is not the delegation from the parent zone.
> 
> The same query to PCH doesn't return any such delegation:
> 
> $ dig +norec @bd-ns.anycast.pch.net. com.bd. ns
> ...
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52571
> 
> $ dig +norec @bd-ns.anycast.pch.net. foobar.com.bd. a
> ...
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30903
> 
> What this means is:
> 
> * bd, com.bd and net.bd (etc) are separate zone files
> 
> * Inside each zone file it lists the correct set of nameservers for that zone. So if I query a nameserver which holds the com.bd zone, I get the NS records for com.bd
> 
> * But as you said, inside the bd zone it is missing the NS records (and glue, where needed) to delegate to the child zones.
> 
> So a server which holds bd but not com.bd treats all com.bd names as non-existent, rather than delegating.
> 
> This in turn means that up to 1/4 of name resolutions for .bd are currently being returned as NXDOMAIN, which is a REALLY REALLY BAD situation. Customers are being affected.
Yes, that is REALLY REALLY REALLY BAD.

> 
> This needs immediate action. If you can't get the delegation NS records added to the .bd zone quickly then:

Yes, very immediate.

> 
> - remove the NS record pointing at PCH server from the .bd zone file
If they can edit the zone file, rather than removing any server, they should just try and fix the problem. They just need to add couple of lines to fix the delegation, that is all. If that seems really really like a lot of work then they can go ahead and remove the server.

> 
> Even this will take some time to propagate, so:
> 
> - PCH server should also be configured to stop answering for .bd  (a lame delegation is better than returning wrong NXDOMAIN responses)
Yes, if it's not going to get fixed going lame is better than giving NXDOMAINs.

Thanks.

> 
> Regards,
> 
> Brian.

-------------- 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/20160912/6545f716/attachment.pgp>