Crufty DNS Info Stored in 'scutil' Causing Name Resolution Problems
I have a user on my network with a strange problem that I think resulted from a recent upgrade of MacOS (not sure if it was 10.6.5 or 10.6.4 as I'm not sure how often he uses the application that exercises the problem).
The issue is that his system cannot resolve DNS names against my internal nameservers but only for one domain (our internal Active Directory domain, company.global).
Digging into this, I see a bunch of entries in the output of 'scutil --dns'. The ones at the end are curious, because they're not being returned from my DHCP server, and are old domains, nameservers, etc.:
resolver #1
domain : api.global
nameserver[0] : 192.168.12.30
nameserver[1] : 192.168.12.31
nameserver[2] : 192.168.1.5
nameserver[3] : 10.1.1.5
order : 200000
[mDNS stuff snipped]
resolver #8
domain : aa.company.com
nameserver[0] : 192.168.12.21
timeout : 3
resolver #9
domain : company.global
nameserver[0] : 192.168.12.21
timeout : 3
resolver #10
domain : company.local
nameserver[0] : 192.168.12.21
timeout : 3
resolver #11
domain : dv.company.local
nameserver[0] : 192.168.12.21
timeout : 3
These entries also don't have an 'order' value associated with them. My theory is that, because he is trying to resolve something in 'company.global', the resolver library is finding 'resolver #9' and 'resolver #1' for the same domain, but because #9 has a zero order, it is trying to use that one, and there's no DNS server at that address.
Really what I'm wondering is where these list of resolvers are coming from. Looking at the output of 'scutil list' and examining the various DNS-related settings, I don't see anything there. The scutil docs are terrible, so I don't know where this crufty stuff is coming from. I suspect if I could delete it things would work properly.
I could do some packet sniffing and see if I'm right, but I don't have admin access on his system yet, and I still need to figure out how to get rid of the unneeded 'resolvers'.
Message was edited by: Brian Spolarich
The issue is that his system cannot resolve DNS names against my internal nameservers but only for one domain (our internal Active Directory domain, company.global).
Digging into this, I see a bunch of entries in the output of 'scutil --dns'. The ones at the end are curious, because they're not being returned from my DHCP server, and are old domains, nameservers, etc.:
resolver #1
domain : api.global
nameserver[0] : 192.168.12.30
nameserver[1] : 192.168.12.31
nameserver[2] : 192.168.1.5
nameserver[3] : 10.1.1.5
order : 200000
[mDNS stuff snipped]
resolver #8
domain : aa.company.com
nameserver[0] : 192.168.12.21
timeout : 3
resolver #9
domain : company.global
nameserver[0] : 192.168.12.21
timeout : 3
resolver #10
domain : company.local
nameserver[0] : 192.168.12.21
timeout : 3
resolver #11
domain : dv.company.local
nameserver[0] : 192.168.12.21
timeout : 3
These entries also don't have an 'order' value associated with them. My theory is that, because he is trying to resolve something in 'company.global', the resolver library is finding 'resolver #9' and 'resolver #1' for the same domain, but because #9 has a zero order, it is trying to use that one, and there's no DNS server at that address.
Really what I'm wondering is where these list of resolvers are coming from. Looking at the output of 'scutil list' and examining the various DNS-related settings, I don't see anything there. The scutil docs are terrible, so I don't know where this crufty stuff is coming from. I suspect if I could delete it things would work properly.
I could do some packet sniffing and see if I'm right, but I don't have admin access on his system yet, and I still need to figure out how to get rid of the unneeded 'resolvers'.
Message was edited by: Brian Spolarich
MacBook Pro 15" 2.5GHz, Mac OS X (10.6.5)
