1

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 204.15.193.162 and 204.15.193.163. My name server is at 24.222.7.12.

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 24.222.7.12 and run 

dig @204.15.193.162 digbypines.ca

I would get 

;; connection timed out; no servers could be reached

If I tried to telnet to 204.15.193.162 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 192.168.0.12#53(192.168.0.12) 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 192.36.148.17#53(i.root-servers.net) in 120 ms

digbypines.ca. 86400 IN NS ns2.extremehosting.ca. digbypines.ca. 86400 IN NS ns1.extremehosting.ca. ;; Received 114 bytes from 156.154.101.4#53(l.ca-servers.ca) 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 @204.15.193.163 ns2.extremehosting.ca successfully from my name server's command line.

Improve this question
5
  • 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, 2011 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, 2011 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, 2011 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, 2011 at 22:44
  • @womble. Thank you. I've updated the question with more specific data.
    – Keith
    Sep 8, 2011 at 12:58

2 Answers 2

Reset to default
3

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.

Improve this answer
0

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

$ nslookup
>server 204.15.193.162
Default server: 204.15.193.162
Address: 204.15.193.162#53
> www.digbypines.ca
Server:     204.15.193.162
Address:    204.15.193.162#53

www.digbypines.ca   canonical name = digbypines.ca.
Name:   digbypines.ca
Address: 204.15.193.162
>

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

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .