Snow leopard broke my dns

Sure thing:
----------------------------------

DNS configuration

resolver #1
domain : gis
nameserver[0] : 192.168.192.7
nameserver[1] : 192.168.192.4
nameserver[2] : 192.168.192.5
order : 200000

resolver #2
domain :<myusername>.members.mac.com.
options : pdns
timeout : 5
order : 150000

resolver #3
domain : local
options : mdns
timeout : 2
order : 300000

resolver #4
domain : 254.169.in-addr.arpa
options : mdns
timeout : 2
order : 300200

resolver #5
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300400

resolver #6
domain : 9.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300600

resolver #7
domain : a.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300800

resolver #8
domain : b.e.f.ip6.arpa
options : mdns
timeout : 2
order : 301000
macbookpro:~ gmelendez$

Thanks Chingachgook. Assuming that 192.168.192.7, 192.168.192.4, and 192.168.192.5 all return the same results no matter which server you ask, everything should be working fine. What seems to be the problem?

I should know this, Snoop, but I'm afraid those brain cells are dead. :-o

What syntax do I use to resolve a name using a specific DNS server?

And the issue is internal application servers intermittently become unreachable - including Exchange and a timekeeping app server.

Chingachgook wrote:
What syntax do I use to resolve a name using a specific DNS server?

dig @4.2.2.1 www.apple.com

Thanks, JohnDCCIU and Snoop.

Resolution from that third server (.5) is resolving differently from the other two. I don't understand it's purpose because it's resolving like the client is external (giving externally-valid resolution, but not valid from inside the private net). So I can use these results to beat up on the IT support guys because this is basically not right.

Cheers

I suspect the IT guys will say that in a system using cascading DNS resolution that third server allows DNS queries to the outside world to still function even if the two (presumably cacheing) internal servers go down.

Actually they fixed it by dropping that last DNS server out of the list pushed to DHCP clients.

Since this is a private network and all outside access is NAT'd, they had no business using that third server for internal name resolutions. I suspect it's configured the way it is for some reverse lookup purposes but it has no use as an internal DNS server. The resolution that was failing was to internal app servers - servers that have different resolution to an outside client accessing those boxes from the Internet.

Anyway, it all works now - no more intermittent connectivity loss. 🙂

I found some interesting findings about 10.6 and 10.6.1 dns/resolution issues within my companies network.

Ping didn't work on my server sql
so I did nslookup (worked)
so I tried dig (didn't work)
I tried dig fully qualified (did work)
why?
eolson:~ eolson$ nslookup sql
Server: 192.168.0.12
Address: 192.168.0.12#53

Name: sql.harmonic.local
Address: 192.168.0.55

eolson:~ eolson$ dig sql

; <<>> DiG 9.6.0-APPLE-P2 <<>> sql
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22204
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sql. IN A

;; Query time: 2 msec
;; SERVER: 192.168.0.12#53(192.168.0.12)
;; WHEN: Mon Sep 14 10:59:18 2009
;; MSG SIZE rcvd: 21

eolson:~ eolson$ dig sql.harmonic.local

; <<>> DiG 9.6.0-APPLE-P2 <<>> sql.harmonic.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35258
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;sql.harmonic.local. IN A

;; ANSWER SECTION:
sql.harmonic.local. 1200 IN A 192.168.0.55

;; Query time: 10 msec
;; SERVER: 192.168.0.12#53(192.168.0.12)
;; WHEN: Mon Sep 14 10:59:25 2009
;; MSG SIZE rcvd: 52

eolson:~ eolson$

This is normal.

dig(1) doesn't use the domain keyword in /etc/resolv.conf to search various domains - it must be supplied a FQDN unless the

<pre>+search</pre>

option is provided:

QUERY OPTIONS

\[ … ]

+\[no]search
Use \[do not use] the search list defined by the searchlist or domain directive in resolv.conf (if
any). The search list is not used by default.

http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/m an1/dig.1.html

Try flushing the local DNS cache dscacheutil -flushcache . I went through the process of dropping dns servers from my setup so I was just using the one local dns but reverting the default dns settings and doing this flush has fixed it, for me anyway

Had the same problem, but had only one dns server from dhcp (a home adsl/wlan/nat-box). I configured it to return my isp:s dns servers IPs not it's own IP. Started to work. That prompted me to try our iPod touch (which has had problems in some wlans, including our home wlan) and that also started to work properly. So I think this problem is rooted deep in the OS.

There may be more to it than multiple DNS servers. Here's what I've run into...

My LAN is behind a SmoothWall 3.0 server (all updates applied, currently through #5). I have an outside DNS server that I run as well. The new server I just built is named "redmine" and internally is 192.168.0.31. Externally, it's a CNAME from a DynDNS name "jaeger.dnsalias.net" which resolves to a public IP. Sine I also wish to be able to use the "jaeger.dnsalias.net" name properly from inside my network, inside it is assigned 192.168.0.44.

Still with me? 🙂

SmoothWall assigns all machines their addresses and network settings via DHCP. It only hands out one DNS address - 192.168.0.1. According to everything I've read here, the Mac is picking up the settings fine.

Now here's what happens...

If I run "dscacheutil -flushcache" and then use Safari or Firefox to browse "redmine", it works... For about two minutes. When it quits working, pinging "redmine" reports a hostname of jaeger.dnsalias.net and an IP of 192.168.0.44. Of course, nslookup and dig still report 192.168.0.31. It's as if the first lookup finds the CNAME from a public DNS server somewhere, although none is configured. When it looks up "jaeger.dnsalias.net", it's finding the internal assignment.

Re-running "dscacheutil -flushcache" fixes it for another couple minutes.

Serious weirdness going on here.

Scott

The external record is coming from somewhere - Mac OS X isn't just making it up.

So either a manual DNS server is specified somewhere that is being queried, or the SmoothWall is occasionally returning the external entry.

Either way, it sounds like a problem that can be solved in configuration.

dscacheutil -flushcache

Where a user has more than one location (defined in the Network pane of System Preferences), does a switch from one location to another lead to a flush?

a bug or a design decision done to perform the equivalent of the BIND "rotate" functionality

I wonder whether clues re: design may be gained from differences between
<http://www.opensource.apple.com/source/configd/configd-212.2/get-mobility-info? f=text>
and (in the tree for 10.6.1)
<http://www.opensource.apple.com/source/configd/configd-289/get-mobility-info?f= text>