Currently Being ModeratedJul 10, 2013 10:35 AM (in response to quarfie)
Are there any errors logged for the DNS server? (Check the DNS server logs for diagnostics and details related to the server. I've seen cases where the server is listed as running in Server Admin.app or in Server.app, but it really wasn't running, or wasn't running correctly.)
As for the terminal, you can specify the IP address of the target DNS server with the dig command at the Terminal.app prompt:
dig @18.104.22.168 www.apple.com
That dig command asks Google DNS (the server at IP address 22.214.171.124) for an IP address of the Apple web servers. Substitute your local IP address and your local host names for translation, and see what you get.
I would not recommend the "secondary" be a public DNS server, as which DNS server gets selected for a DNS query is not particularly deterministic. I much prefer to have "peer" servers specified; primary and secondary DNS servers that have the local address(es) and local DNS domain names, and to avoid referencing off-LAN DNS servers save via the root server and related queries generated from these local DNS servers.
Currently Being ModeratedJul 10, 2013 11:27 AM (in response to MrHoffman)
using dig I get the exact same result as nslookup.
When I click the "log" tab in the DNS service in Server Admin, the only entry is "logfile turned over" (with today's date). I've had this issue for a long time, even though I have the "Log Level" set to "Debug" (which should give the most detailed logging right?).
Thanks for suggestion re: using only local DNS servers on the LAN. I definitely have been meaning to bring in an expert to audit my DNS setup!
Currently Being ModeratedJul 10, 2013 12:31 PM (in response to quarfie)
To confirm, you're using the @ notation on the dig, and you've specified the IP address of your DNS server, correct?
You can see if the DNS server (named) is really running with the following Terminal.app command:
sudo lsof -i -P | grep -i ":53"
That'll report anything on TCP and UDP port 53 (which is used by DNS) (plus possibly a few ports beginning with 53 that you can ignore). If things are working, you should see some named processes.
In general, you'll want to post the specific command used, and the full text of the response, as a starting point. While it is distinctly possible there's an IP networking or cabling or DNS error here, there's not enough information posted to hint at a direction. (It would definitely appear that the DNS server is not running, though.)
Here's some DNS server configuration reading for you. That sequence is for Snow Leopard 10.6, but will work the same with OS X Server on Lion 10.7 and Mountain Lion 10.8, if you've selected Show All Records within Server.app.
Currently Being ModeratedJul 10, 2013 1:37 PM (in response to MrHoffman)
Thanks for that link. It looks about at my level so I'll have a read tonight. I am on 10.6.8
Here's what I got back from the command you suggested (looks like all of these are just ports starting with "53" - confirming that DNS is not running?)
mDNSRespo 36 _mdnsresponder 8u IPv4 0xffffff800fe25980 0t0 UDP *:5353
mDNSRespo 36 _mdnsresponder 9u IPv6 0xffffff800fe25840 0t0 UDP *:5353
mDNSRespo 36 _mdnsresponder 50u IPv4 0xffffff8012030c00 0t0 UDP *:53697
mDNSRespo 36 _mdnsresponder 51u IPv6 0xffffff8012030340 0t0 UDP *:53697
Python 50 _jabber 4u IPv4 0xffffff8012cc4da8 0t0 TCP localhost:49277->localhost:5347 (ESTABLISHED)
Python 75 _jabber 3u IPv4 0xffffff8010120a08 0t0 TCP localhost:49177->localhost:5347 (ESTABLISHED)
resolver 406 _jabber 4u IPv4 0xffffff8012970418 0t0 TCP localhost:49172->localhost:5347 (ESTABLISHED)
sm 407 _jabber 5u IPv4 0xffffff80129727b8 0t0 TCP localhost:49170->localhost:5347 (ESTABLISHED)
router 408 _jabber 4u IPv4 0xffffff80127621c8 0t0 TCP localhost:5347 (LISTEN)
router 408 _jabber 5u IPv4 0xffffff80127615e8 0t0 TCP localhost:5347->localhost:49166 (ESTABLISHED)
router 408 _jabber 6u IPv4 0xffffff8012760a08 0t0 TCP localhost:5347->localhost:49167 (ESTABLISHED)
router 408 _jabber 7u IPv4 0xffffff80127627b8 0t0 TCP localhost:5347->localhost:49168 (ESTABLISHED)
router 408 _jabber 8u IPv4 0xffffff80129721c8 0t0 TCP localhost:5347->localhost:49170 (ESTABLISHED)
router 408 _jabber 9u IPv4 0xffffff8012abfda8 0t0 TCP localhost:5347->localhost:49172 (ESTABLISHED)
router 408 _jabber 10u IPv4 0xffffff8012abe5e8 0t0 TCP localhost:5347->localhost:49177 (ESTABLISHED)
router 408 _jabber 11u IPv4 0xffffff8012cc47b8 0t0 TCP localhost:5347->localhost:49277 (ESTABLISHED)
c2s 409 _jabber 4u IPv4 0xffffff8012760ff8 0t0 TCP localhost:49167->localhost:5347 (ESTABLISHED)
mu-confer 410 _jabber 6u IPv4 0xffffff8011d14a08 0t0 TCP localhost:49168->localhost:5347 (ESTABLISHED)
s2s 411 _jabber 4u IPv4 0xffffff8012761bd8 0t0 TCP localhost:49166->localhost:5347 (ESTABLISHED)
Currently Being ModeratedJul 10, 2013 3:50 PM (in response to quarfie)
Yeah; your DNS server isn't running. You'd see some "named" processes if it was.
In OS X Server 10.6.8 in Server Admin.app (unlike in various newer versions ), you can crank up the DNS debugging level through the GUI. Do that. Launch Server Admin.app, select the server, select DNS, select settings, and set the DNS log level settings to "debug", and see if you can get something more logged.
The default DNS log file can be found and displayed via Console.app (Applications > Utilities) or from Terminal.app via the /Library/Logs/named.log file.
You might also find some relevant errors in /var/log/system.log file, depending on why the DNS startup is cratering.
Console.app can also show you a mass of messages, and you might also see where named is encountering error(s). If it's the usual crash-restart schtick, you'll get the same block of restart message(s) logged in the Console.app messages every five or ten or fifteen seconds; whatever the restart interval for the DNS server.
Though it's a little late here, I'd generally recommend configuring a less-interruptible power supply — a LIPS, as they're never truly uninterruptible — battery backup — as OS X Server doesn't really like having the power yanked out.
Currently Being ModeratedJul 10, 2013 4:30 PM (in response to MrHoffman)
I do have a "LIPS" (ha) but emphasis on the L this time it seems. I actually just realized that this problem started over a week ago when one machine stopped being able to connect to file sharing with the domain name. I guess all the others had the correct DNS cached until the blackout forced everyone to restart.
I did set the log level to "Debug" in Server Admin, but I still don't get any entries in named.log. Other than "log file turned over". It seems the log file is archived every day and 5 days are kept. Every one simply has the one entry "log file turned over"
However when I click "All messages" in Console, and type "named" in the filter by, I do see lots of relevent data, and this happens every 10 seconds!
13-07-10 7:11:06 PM named starting BIND 9.6-ESV-R4-P3 -f 13-07-10 7:11:06 PM named built with '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--disable-dependency-tracking' '--sysconfdir=/private/etc' '--localstatedir=/private/var' '--enable-atomic=no' '--with-libxml2=/usr/include/libxml2' 'CFLAGS=-arch x86_64 -arch i386 -arch ppc -g -Os -pipe ' 'LDFLAGS=-arch x86_64 -arch i386 -arch ppc ' 'CXXFLAGS=-arch x86_64 -arch i386 -arch ppc -g -Os -pipe ' 13-07-10 7:11:06 PM named /etc/dns/publicView.conf.apple:1: undefined ACL '192.168.7.*' 13-07-10 7:11:06 PM named loading configuration: failure 13-07-10 7:11:06 PM named exiting (due to fatal error) 13-07-10 7:11:06 PM com.apple.launchd (org.isc.named) Exited with exit code: 1 13-07-10 7:11:06 PM com.apple.launchd (org.isc.named) Throttling respawn: Will start in 10 seconds
So I removed 192.168.7.* from the "Accept recursive queries from the following networks" box in Server Admin, and now it seems everything works.
I added that entry 4 months ago! I think I had added the entry while trying to get my remote office IP phones working with the name server, but it never solved the problem and the phones still refuse to use the name server.
Anyway, my immediate problem is solved. thank you so much! I'll check out your reading materials tonight and see if I can figure out the less urgent phone issues!