BIND cannot resolve specific domain name - is INEXPLICABLE
Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
BIND cannot resolve specific domain name - is INEXPLICABLE
Very bizarre problem.
I have a server, running FC4 with BIND9. I am authoritative for several domains, I have fixed IPs, reverse PTR records on both my end AND my ISP's end. Everything works beautifully.
Except that I CANNOT resolve 'cox.net' from MY nameserver.
If I change the /etc/resolv.conf or (on my winblowz box) if I change my DNS settings to point to ANY other major nameserver I know of, I can immediately resolve it using 'dig' or 'nslookup', etc ...
I have gone as far as building a 2nd server (this one is DEBIAN, but also running BIND9), and set it to resolve off itself -- SAME PROBLEM.
This is the ONE AND ONLY domain on the planet that I seem to have problems resolving.
Cox just so happens to be my ISP. I have called them, they have no explanation, however i agree that its probably not them. They checked all of their logs, I am not being blocked for any reason.
I have tried dumping my BIND cache file on the FC4 box. No change. I have done rndc flush / rndc reload, I have reviewed each and every zone file on my system, looked for ANYTHING that could somehow explain this. Found nothing.
Do you have forwarders set up within BIND? And if so are those forwarders the same nameservers that are authoritative for cox.net?
ns.west.cox.net. 80716 IN A 126.96.36.199
ns.cox.net. 80716 IN A 188.8.131.52
ns.east.cox.net. 80716 IN A 184.108.40.206
If the problem persists, you could post your full named.conf and we'll take a look.
You also could ask for permission from cox to slave their zone on your machine. That way you get a perfect copy of their zone locally, which should allow resolution. Also, for more help, please post the full output of
dig cox.net +trace
from the DNS box. Don't try nslookup, it is useless for DNS troubleshooting. Programmers like it because it gives short answers they don't need to parse, but it gives way too little info to find where the problems are at beyond "yes this works" or "no this doesn't".
I would not use a forward. I don't use them under any circumstances. I will slave zones as I suggested you try, but without doing the things I asked for (the dig +trace and show your named.conf) I can't help troubleshoot it. Chances are good you have some forward in place that caused the problem, but that's just a guess, as I have nothing to look at.
I have in fact done dig and traceroute. Both end in failure:
"No nameservers could be contacted"
I don't think this is not a route issue, nor do i think it is a problem with my named.conf. The way I proved this was building the 2nd nameserver I mentioned ; by using a virgin configuration w/o any of my modifications, the problem still occured.
I know this is not a route issue because if it were, it would be a problem with a route to one of the global root nameservers (I do not use Cox for any reason except the line coming into my office, I dont use their mail server nor their dns server). Since putting their DNS addresses into my laptop (for a test) and being able to resolve cox.net just fine, I know it was something obscure that is wrong with my machine.
But the 'forward' zone you spoke of was the very thing that immediately solved the problem. To date, until this occured, I have never used forwards. All of the records on the main nameserver were master records, and they have always worked flawlessly. Keep in mind, this is not a global forward, its merely for requests specifically for cox.net.
This was very unusual ; personally, after thinking about this for a long time, I think cox WAS blocking me and maybe they didn't know it. I have no idea why they would block me - for one, nothing illegal was ever or will ever be done on this connection, and also its a commercial Internet Connection. There are no restrictions of any kind. I had to call them once to create PTR records for me, and I openly explained why I needed them (mail server needs it to send to some orgs). They KNOW what I'm doing, so it doesn't make sense to block me (but hey, thats Cox for you) =)
The ONE thing I can think of which would cause them to block me was that once my mail server was used to *attempt* spam ; I had been reconfiguring my postfix setup and accidentally made myself an open-relay and someone exploited it. When I checked the queue, 12000+ msgs were queued, however none were delivered due to an error in my main.cf file (thank god). So I can't say for certain that Cox didn't get wind of this somehow and made a pre-emptive block on my connection to them.
However wouldn't such a breach of regulations result in (a) loss of service altogether and/or (b) a phonecall inquiring on such breaches?
I may never know. But the fwd is working and I appreciate your time =)
Traceroute will tell you nothing. Tracerouting would depend on the DNS lookup, which is failing. I asked for dig +trace, which will show every step your DNS server takes down to the roots and back up to the supposedly authoritative DNS for cox.net.
It makes no sense to ever block DNS info. You'd have to be a major league spammer to have a domain intentionally block giving their info to you, well beyond the level of having an open relay server sending out spam through a static IP dns connection.
I am very curious what is happening here. If you remove the forward for cox and put in this command, I may be able to fugure out what is happening:
jim@jimsworktop:~$ dig +trace cox.net
; <<>> DiG 9.3.4 <<>> +trace cox.net
;; global options: printcmd
. 180240 IN NS c.root-servers.net.
. 180240 IN NS d.root-servers.net.
. 180240 IN NS e.root-servers.net.
. 180240 IN NS f.root-servers.net.
. 180240 IN NS g.root-servers.net.
. 180240 IN NS h.root-servers.net.
. 180240 IN NS i.root-servers.net.
. 180240 IN NS j.root-servers.net.
. 180240 IN NS k.root-servers.net.
. 180240 IN NS l.root-servers.net.
. 180240 IN NS m.root-servers.net.
. 180240 IN NS a.root-servers.net.
. 180240 IN NS b.root-servers.net.
;; Received 436 bytes from 192.168.1.1#53(192.168.1.1) in 40 ms
net. 172800 IN NS A.GTLD-SERVERS.net.
net. 172800 IN NS B.GTLD-SERVERS.net.
net. 172800 IN NS C.GTLD-SERVERS.net.
net. 172800 IN NS D.GTLD-SERVERS.net.
net. 172800 IN NS E.GTLD-SERVERS.net.
net. 172800 IN NS F.GTLD-SERVERS.net.
net. 172800 IN NS G.GTLD-SERVERS.net.
net. 172800 IN NS H.GTLD-SERVERS.net.
net. 172800 IN NS I.GTLD-SERVERS.net.
net. 172800 IN NS J.GTLD-SERVERS.net.
net. 172800 IN NS K.GTLD-SERVERS.net.
net. 172800 IN NS L.GTLD-SERVERS.net.
net. 172800 IN NS M.GTLD-SERVERS.net.
;; Received 510 bytes from 220.127.116.11#53(c.root-servers.net) in 45 ms
cox.net. 172800 IN NS ns.cox.net.
cox.net. 172800 IN NS ns.east.cox.net.
cox.net. 172800 IN NS ns.west.cox.net.
;; Received 134 bytes from 18.104.22.168#53(A.GTLD-SERVERS.net) in 76 ms
cox.net. 86400 IN A 22.214.171.124
cox.net. 86400 IN NS ns.cox.net.
cox.net. 86400 IN NS ns.east.cox.net.
cox.net. 86400 IN NS ns.west.cox.net.
;; Received 150 bytes from 126.96.36.199#53(ns.cox.net) in 57 ms
I'm glad the forward worked for you, but that is more or less a craptacular fix. It solves the problem, but in a very inelegant way. I am curious what is actually happening