LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Server
User Name
Password
Linux - Server This forum is for the discussion of Linux Software used in a server related context.

Notices

Reply
 
Search this Thread
Old 05-01-2007, 01:21 AM   #1
subcon
LQ Newbie
 
Registered: Oct 2005
Posts: 12

Rep: Reputation: 0
Question BIND cannot resolve specific domain name - is INEXPLICABLE


Hello.

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.
 
Old 05-01-2007, 08:33 PM   #2
JimBass
Senior Member
 
Registered: Oct 2003
Location: New York City
Distribution: Debian Sid 2.6.32
Posts: 2,100

Rep: Reputation: 48
Do you have forwarders set up within BIND? And if so are those forwarders the same nameservers that are authoritative for cox.net?
Code:
ns.west.cox.net.        80716   IN      A       68.111.106.76
ns.cox.net.             80716   IN      A       68.1.16.100
ns.east.cox.net.        80716   IN      A       68.1.16.101
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
Code:
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".

Peace,
JimBass
 
Old 05-02-2007, 10:41 AM   #3
subcon
LQ Newbie
 
Registered: Oct 2005
Posts: 12

Original Poster
Rep: Reputation: 0
Smile Resolved

Thank you for responding.

I did end up setting up a forwarder in my /etc/named.conf.local


zone "cox.net" {
type forward;
forwarders { 4.2.2.2 ; 4.2.2.3 ; };
};


And the issue is resolved. I can lookup their MX record and therefore reply to my friend's email which he sent two months ago =)


But what is so vexing is HOW/WHY this happened? I haven't found a single soul who can explain this issue. LOL

Thanks again!
 
Old 05-02-2007, 05:49 PM   #4
JimBass
Senior Member
 
Registered: Oct 2003
Location: New York City
Distribution: Debian Sid 2.6.32
Posts: 2,100

Rep: Reputation: 48
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.

Peace,
JimBass
 
Old 05-03-2007, 02:26 AM   #5
subcon
LQ Newbie
 
Registered: Oct 2005
Posts: 12

Original Poster
Rep: Reputation: 0
Smile

I have in fact done dig and traceroute. Both end in failure:

"No nameservers could be contacted"

or

"Host unknown"

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 =)

Last edited by subcon; 05-03-2007 at 02:28 AM.
 
Old 05-03-2007, 05:56 PM   #6
JimBass
Senior Member
 
Registered: Oct 2003
Location: New York City
Distribution: Debian Sid 2.6.32
Posts: 2,100

Rep: Reputation: 48
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:

Code:
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 192.33.4.12#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 192.5.6.30#53(A.GTLD-SERVERS.net) in 76 ms

cox.net.                86400   IN      A       68.1.17.9
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 68.1.16.100#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

Peace,
JimBass
 
  


Reply

Tags
bind, named


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
DNS http:domain.com resolve to www.domain.com keysorsoze Linux - Networking 3 02-12-2007 04:03 AM
Bouncing specific domain with specific message dlublink Linux - Software 1 08-21-2006 03:29 PM
How do I confiure BIND 9 to resolve my domain name? Glenjosh Linux - Software 2 04-21-2006 04:30 PM
what would make ever virtual domain name resolve to one domain name on my system kuplo Linux - Newbie 1 11-14-2005 07:57 PM
How to resolve base domain name using bind/named? qidwai Linux - Networking 2 05-08-2004 11:46 AM


All times are GMT -5. The time now is 01:10 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration