Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game. |
| Notices |
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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
 |
GNU/Linux Basic Guide
This 255-page guide will provide you with the keys to understand the philosophy of free software, teach you how to use and handle it, and give you the tools required to move easily in the world of GNU/Linux. Many users and administrators will be taking their first steps with this GNU/Linux Basic guide and it will show you how to approach and solve the problems you encounter.
Click Here to receive this Complete Guide absolutely free. |
|
 |
10-19-2008, 03:34 PM
|
#1
|
|
Member
Registered: Jan 2004
Location: Los Angeles
Distribution: Slack64 13.37
Posts: 535
Rep: 
|
Bind Occasionally Doesn't Resolve an Address
I'm running Bind 9.4.2 for a small internal network. Most of the time, it runs fine, but every now and again, it fails to resolve a single address. I haven't noticed any pattern to when this happens, or if there is a pattern to the names that don't resolve.
If I dig, from inside the network, to my NameServer, I don't get any information back. If I dig, to my VoIP adapter, which is between the cable modem and my server, and also running a NameServer, it resolves the address correctly.
If I re-start Bind, and try the same name again, now it will resolve correctly.
So, it looks like Bind, somehow, is using another server, upstream, that can't resolve the address, and doesn't try any others.
Is there any way I can resolve this, without waiting for it to happen, noticing that it's happening, and then bouncing Bind. Or is there any way I can trace this, to see where the issue is happening.
Cheers,
Eddie
|
|
|
|
|
10-19-2008, 03:47 PM
|
#2
|
|
Member
Registered: Oct 2008
Posts: 31
Rep:
|
When it stops resolving, what does
dig +trace
show? Is the nameserver trying the wrong upstream server?
Are you running a caching-only nameserver, or is it an authoritative server for your local network?
|
|
|
|
|
10-19-2008, 10:44 PM
|
#3
|
|
Member
Registered: Jan 2004
Location: Los Angeles
Distribution: Slack64 13.37
Posts: 535
Original Poster
Rep:
|
BTW, the actual domain name has been changed to protect the innocent. 
Firstly, from my server:
Code:
eddie@The-Tardis:~$ dig domainxxx.com
; <<>> DiG 9.4.2-P2 <<>> domainxxx.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48800
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;domainxxx.com. IN A
;; Query time: 373 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Oct 19 12:16:36 2008
;; MSG SIZE rcvd: 33
eddie@The-Tardis:~$ dig +trace domainxxx.com any
; <<>> DiG 9.4.2-P2 <<>> +trace domainxxx.com any
;; global options: printcmd
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
;; Received 376 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
com. 172800 IN NS D.GTLD-SERVERS.NET.
com. 172800 IN NS F.GTLD-SERVERS.NET.
com. 172800 IN NS E.GTLD-SERVERS.NET.
com. 172800 IN NS A.GTLD-SERVERS.NET.
com. 172800 IN NS G.GTLD-SERVERS.NET.
com. 172800 IN NS I.GTLD-SERVERS.NET.
com. 172800 IN NS J.GTLD-SERVERS.NET.
com. 172800 IN NS C.GTLD-SERVERS.NET.
com. 172800 IN NS B.GTLD-SERVERS.NET.
com. 172800 IN NS H.GTLD-SERVERS.NET.
com. 172800 IN NS L.GTLD-SERVERS.NET.
com. 172800 IN NS K.GTLD-SERVERS.NET.
com. 172800 IN NS M.GTLD-SERVERS.NET.
;; Received 493 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 109 ms
domainxxx.com. 172800 IN NS ns1.ipowerdns.com.
domainxxx.com. 172800 IN NS ns1.ipowerweb.net.
domainxxx.com. 172800 IN NS ns1.ipowerdns.com.
domainxxx.com. 172800 IN NS ns1.ipowerweb.net.
;; Received 152 bytes from 192.33.14.30#53(B.GTLD-SERVERS.NET) in 104 ms
Now, using the NameServer on my VoiP box:
Code:
eddie@The-Tardis:~$ dig @192.168.15.1 domainxxx.com any
; <<>> DiG 9.4.2-P2 <<>> @192.168.15.1 domainxxx.com any
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16483
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;domainxxx.com. IN ANY
;; ANSWER SECTION:
domainxxx.com. 172800 IN NS ns1.ipowerweb.net.
domainxxx.com. 172800 IN NS ns1.ipowerdns.com.
;; AUTHORITY SECTION:
domainxxx.com. 172800 IN NS ns1.ipowerweb.net.
domainxxx.com. 172800 IN NS ns1.ipowerdns.com.
;; ADDITIONAL SECTION:
ns1.ipowerweb.net. 2041 IN A 66.96.xxx.xx
ns1.ipowerweb.net. 2041 IN A 66.96.xxx.xxx
;; Query time: 354 msec
;; SERVER: 192.168.15.1#53(192.168.15.1)
;; WHEN: Sun Oct 19 12:17:52 2008
;; MSG SIZE rcvd: 152
eddie@The-Tardis:~$ dig @192.168.15.1 +trace domainxxx.com any
; <<>> DiG 9.4.2-P2 <<>> @192.168.15.1 +trace domainxxx.com any
; (1 server found)
;; global options: printcmd
. 17497 IN NS A.ROOT-SERVERS.NET.
. 17497 IN NS E.ROOT-SERVERS.NET.
. 17497 IN NS D.ROOT-SERVERS.NET.
. 17497 IN NS L.ROOT-SERVERS.NET.
. 17497 IN NS B.ROOT-SERVERS.NET.
. 17497 IN NS M.ROOT-SERVERS.NET.
. 17497 IN NS F.ROOT-SERVERS.NET.
. 17497 IN NS G.ROOT-SERVERS.NET.
. 17497 IN NS K.ROOT-SERVERS.NET.
. 17497 IN NS J.ROOT-SERVERS.NET.
. 17497 IN NS H.ROOT-SERVERS.NET.
. 17497 IN NS I.ROOT-SERVERS.NET.
. 17497 IN NS C.ROOT-SERVERS.NET.
;; Received 512 bytes from 192.168.15.1#53(192.168.15.1) in 143 ms
com. 172800 IN NS H.GTLD-SERVERS.NET.
com. 172800 IN NS F.GTLD-SERVERS.NET.
com. 172800 IN NS A.GTLD-SERVERS.NET.
com. 172800 IN NS E.GTLD-SERVERS.NET.
com. 172800 IN NS J.GTLD-SERVERS.NET.
com. 172800 IN NS B.GTLD-SERVERS.NET.
com. 172800 IN NS M.GTLD-SERVERS.NET.
com. 172800 IN NS L.GTLD-SERVERS.NET.
com. 172800 IN NS K.GTLD-SERVERS.NET.
com. 172800 IN NS D.GTLD-SERVERS.NET.
com. 172800 IN NS C.GTLD-SERVERS.NET.
com. 172800 IN NS G.GTLD-SERVERS.NET.
com. 172800 IN NS I.GTLD-SERVERS.NET.
;; Received 493 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 35 ms
domainxxx.com. 172800 IN NS ns1.ipowerdns.com.
domainxxx.com. 172800 IN NS ns1.ipowerweb.net.
domainxxx.com. 172800 IN NS ns1.ipowerdns.com.
domainxxx.com. 172800 IN NS ns1.ipowerweb.net.
;; Received 152 bytes from 192.26.92.30#53(C.GTLD-SERVERS.NET) in 119 ms
I'm not 100% sure what you mean by your last question. Bind is used to provide name resolution, to my internal network, both for devices with fixed IPs, and for other devices after an IP is handed out by DHCP, which all works perfectly well. It is also the NameServer referred to by all the internal machines. But, it does not publish any information externally.
Cheers,
Eddie |
|
|
|
|
10-20-2008, 07:56 PM
|
#4
|
|
Member
Registered: Oct 2008
Posts: 31
Rep:
|
> I'm not 100% sure what you mean by your last question.
Well, I was wondering if bind was only passing requests upstream or if it was configured to pass some requests upstream while resolving others itself. But from your description, since it resolves the remote address correctly after a restart, it doesn't sound like a configuration issue (eg, trying to answer even remote queries itself -- seems it is forwarding them upstream correctly).
Since it works after a restart, it can't be a config file issue (or at least *shouldn't* be).
But the one thing that would change after a restart would be that bind empties its cache.
Perhaps
rndc dumpdb
will show an errant entry for the domain in question? Failing that,
rndc flush
should flush the cache. If it works after that, it's a cache problem. So then it reduces to a problem of determining what invalid data is getting into the cache and from where.
|
|
|
|
|
10-21-2008, 02:48 AM
|
#5
|
|
Senior Member
Registered: Jun 2008
Posts: 2,529
Rep:
|
I'm confused by your two examples - neither shows resolution of any names other than NS RR.s
|
|
|
|
|
10-21-2008, 01:45 PM
|
#6
|
|
Member
Registered: Jan 2004
Location: Los Angeles
Distribution: Slack64 13.37
Posts: 535
Original Poster
Rep:
|
Quote:
Originally Posted by Mr. C.
I'm confused by your two examples - neither shows resolution of any names other than NS RR.s
|
Duhhhhh. I really need to get my glasses fixed, don't I. 
This particular case really is a missing A record at the destination NS.
Guess I'll have to wait for another occurrence of my "mystery non-resolver" to try out the suggestions above.
Cheers,
Eddie |
|
|
|
|
10-21-2008, 02:34 PM
|
#7
|
|
Senior Member
Registered: Jun 2008
Posts: 2,529
Rep:
|
Also take note that the ANY query does not mean ALL RRs. It means essentially "give me what you have". It does not cause a name server to perform a zone transfer. Consider any foreign domain - one wouldn't expect an ANY query to either enumerate through an infinite number of possible queries, nor expect that the foreign domain will just hand over all of its RRs.
|
|
|
|
| Thread Tools |
Search this Thread |
|
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 04:31 PM.
|
|
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
|
 Latest Threads
LQ News
|
|
