I've an interesting bug in my master name server. I'm running Fedora Linux, with bind 9.3.4. The server is planned to be replaced, as it's quite old, but I have to make it work in the meantime. The problem is that my name server cannot resolve digbypines.ca. The authoritative name servers for digbypines.ca are and My name server is at

A firewall bug (where outgoing DNS connections were SNATted to port 53) made it impossible to contact the nameservers for digbypines.ca. So if I were to ssh into my name server at and run

dig @ digbypines.ca 

I would get

;; connection timed out; no servers could be reached

If I tried to telnet to on port 53, I'd also get a timeout. That being the case, I removed the SNAT firewall rule, and now the above commands work as expected. But here's the interesting part.

For some reason, I can't convince bind to talk to digbypine's name servers! Even after fixing the SNATting, it won't work.

Running 'dig +trace digbypines.ca' shows that I'll get the NS records, but it refuses to resolve them:

dig +trace digbypines.ca

; <<>> DiG 9.3.4-P1 <<>> +trace digbypines.ca ;; global options: printcmd . 516709 IN NS
i.root-servers.net. . 516709 IN NS
j.root-servers.net. . 516709 IN NS
k.root-servers.net. . 516709 IN NS
l.root-servers.net. . 516709 IN NS
m.root-servers.net. . 516709 IN NS
a.root-servers.net. . 516709 IN NS
b.root-servers.net. . 516709 IN NS
c.root-servers.net. . 516709 IN NS
d.root-servers.net. . 516709 IN NS
e.root-servers.net. . 516709 IN NS
f.root-servers.net. . 516709 IN NS
g.root-servers.net. . 516709 IN NS
h.root-servers.net. ;; Received 408 bytes from in 1 ms

ca. 172800 IN NS l.ca-servers.ca. ca.
172800 IN NS sns-pb.isc.org. ca. 172800 IN NS m.ca-servers.ca. ca. 172800 IN
NS c.ca-servers.ca. ca. 172800 IN NS
a.ca-servers.ca. ca. 172800 IN NS
j.ca-servers.ca. ca. 172800 IN NS
f.ca-servers.ca. ca. 172800 IN NS
k.ca-servers.ca. ca. 172800 IN NS
z.ca-servers.ca. ca. 172800 IN NS
e.ca-servers.ca. ;; Received 430 bytes from in 120 ms

digbypines.ca. 86400 IN NS ns2.extremehosting.ca. digbypines.ca. 86400 IN NS ns1.extremehosting.ca. ;; Received 114 bytes from in 31 ms

dig: couldn't get address for 'ns2.extremehosting.ca': failure

I'm a little stuck. I called their support group, and they've assured me that my IPs aren't blocked. I'm really not sure how I can dig on their name servers on the command line, yet cannot conduct the same operation through bind.

I've also tried restarting bind, networking, and running 'rndc flush'. No love.

I can resolve digbypines.ca and indeed ns2.extremehosting.ca and ns1.extremehosting.ca from home, so I'm not sure what's going on.

I can also run dig @ ns2.extremehosting.ca successfully from my name server's command line.

  • 1
    Your question is rather unclear -- I have no idea what your symptoms even are, let alone what the cause might be. – womble Aug 31 '11 at 20:34
  • My symptoms are: I can communicate with their name server, but I can't resolve domain names. I can dig on their server from mine, I can telnet to their server too. But named on my server can't communicate with theirs at all. From named's perspective, it's almost like I'm blocked from them. But since I can telnet, and dig them from the same IP... well, I can't be blocked! – Keith Aug 31 '11 at 20:39
  • Agreed, be specific. Do you have two network cards in the server using two different DNS hosts? I mean, is one of them set to itself or something funky, and the BIND: is it using the faulty external DNS records? Just check that out. A possibility. – U4iK_HaZe Aug 31 '11 at 20:41
  • @Keith: Don't add diagnostic information in a comment, edit your question to add that information and make it more clear. – womble Aug 31 '11 at 22:44
  • @womble. Thank you. I've updated the question with more specific data. – Keith Sep 8 '11 at 12:58

Well, I solved it. Turns out the sysadmin before me had forced all outgoing queries onto port 53. extremehosting.ca's name servers seem to block incoming connections on port 53, which originate on port 53, and as such I wasn't able to communicate with them.

By removing these lines from named.conf:

query-source    port 53;
query-source-v6 port 53;

and confirming the firewall wouldn't cause any further issue, name resolution works again.

Also, I found this article which helps determine your name resolver's source-port behaviour to be hugely helpful. The side effect of sorting out this DNS problem is that I've also plugged a potential name-cache poisoning vulnerability.

Thanks to all who've commented.


Hmm, what happens when you use nslookup to talk to their servers? IE:

$ nslookup
Default server:
> www.digbypines.ca

www.digbypines.ca   canonical name = digbypines.ca.
Name:   digbypines.ca

That should let you know if it's a BIND problem or a firewall one.

  • Seems to work fine. I must have a bind issue, but I'll be darned if I knew what it was. – Keith Sep 20 '11 at 13:53
  • using both nslookup and dig work perfectly.The mystery continues... – Keith Sep 21 '11 at 23:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.