Previous 1 3 4 5 6 7 Next 149 Replies Latest reply: Apr 9, 2010 4:44 PM by jice0 Go to original post
  • Snoop Dogg Level 4 Level 4 (1,265 points)
    Hi Barnski. The system no longer uses Directory Services for DNS caching. It now uses mDNSResponder, so your dscacheutil commands aren't going to work. If you want to look at mDNSResponder's record cache, you'll want to do this...

    *sudo killall -INFO mDNSResponder*

    Then look in system.log.
  • William Kucharski Level 6 Level 6 (14,890 points)
    However the dscacheutil command is still the only way to show what Mac OS X's internal resolver has come up with.
  • Barnski Level 1 Level 1 (0 points)
    *scutil --dns* gives the following, in full:

    DNS configuration

    resolver #1

    search domain[0] : internal

    nameserver[0] : 192.168.0.10
    
nameserver[1] : 192.168.0.254

    order : 200000

    resolver #2
    domain : username.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

    For my tcpdump I just did a *tcpdump -i en0 -vvv -n -s 0 -w DumpFile.dmp* and then scanned the dump file by hand with a *tcpdump -r DumpFile.dmp*. No filtering on port, name or anything, and still no mention of the first DNS server.

    Your assumption is correct: 192.168.0.254 is indeed "smoothwall.domain", although it is not known by that FQDN by anyone. It knows itself purely by the hostname "smoothwall" or "smoothwall.internal", and the internal DNS server has a host record for it at smoothwall.internal. I have no idea where smoothwall.domain was generated.

    Finally, my nameservers are not DHCP-specified; on this client they are manually assigned along with all the other IP information. However, DHCP on this network specifies exactly the same DNS settings, and Snow Leopard laptops that use DHCP do experience the same issue. I would therefore discount static or DHCP assignment of DNS servers as a factor (in my case, at least).
  • William Kucharski Level 6 Level 6 (14,890 points)
    My fault, smoothwall.domain isn't an actual domain name, it's:

    hostname.port

    so it's "smoothwall" responding on the "domain" port. My bad.

    That having been said, I can't imagine what's causing the resolver to not use your primary nameserver unless it failed a query and so mDNS has somehow marked that nameserver as "bad."
  • Barnski Level 1 Level 1 (0 points)
    Snoop Dogg; nice pointer. As suggested, I performed a killall on the mDNSResponder and examined the system log (and man, there's a lot of stuff cached in there!).

    The interesting bit is right at the end:
    Sep 8 08:08:46 MacBook mDNSResponder[17]: --------- DNS Servers ----------
    Sep 8 08:08:46 MacBook mDNSResponder[17]: DNS Server . 192.168.0.254:53
    Sep 8 08:08:46 MacBook mDNSResponder[17]: DNS Server . 192.168.0.10:53
    Sep 8 08:08:46 MacBook mDNSResponder[17]: Timenow 0x8B5C2C36 (-1956893642)
    Sep 8 08:08:46 MacBook mDNSResponder[17]: ---- END STATE LOG ----

    So, assuming the DNS servers are queried by mDNSResponder in the order shown in this list, mDNSResponder is indeed querying the DNS servers in the wrong order! - this would explain the behaviour seen, and supports my experience that only specifying the LAN DNS server (as opposed to multiple DNS servers) works.

    Great! - how do we get Apple to fix this?
  • William Kucharski Level 6 Level 6 (14,890 points)
    Barnski,

    Thanks for all your responses to my queries.

    I've just managed to reproduce your behavior somehow, and have filed a bug with Apple, RADAR #7204499:

    scutil --dns shows:

    resolver #1
    domain : comcast.net.
    nameserver\[0] : 208.67.222.222
    nameserver\[1] : 208.67.220.220
    order : 200000

    Indeed, /etc/resolv.conf was generated as:

    #
    # Mac OS X Notice
    #
    # This file is not used by the host name and address resolution
    # or the DNS query routing mechanisms used by most processes on
    # this Mac OS X system.
    #
    # This file is automatically generated.
    #
    domain comcast.net.
    nameserver 208.67.222.222
    nameserver 208.67.220.220

    But the output of "killall -INFO mDNSResponder" shows:

    Sep 8 03:02:32 Sun-MacBookPro mDNSResponder\[27]: --------- DNS Servers ----------
    Sep 8 03:02:32 Sun-MacBookPro mDNSResponder\[27]: DNS Server . 208.67.220.220:53
    Sep 8 03:02:32 Sun-MacBookPro mDNSResponder\[27]: DNS Server . 208.67.222.222:53

    The output clearly shows the DNS Servers in the REVERSE order of that specified.

    This is confirmed by watching DNS traffic with:

    $ tcpdump -n -i en1 port domain

    The following behavior is seen:

    1) A "nslookup microsoft.com." queries the specified name servers in the documented order:

    03:07:50.338737 IP 192.168.0.104.56799 > 208.67.222.222.53: 38560+ A? microsoft.com. (31)
    03:07:50.399542 IP 208.67.222.222.53 > 192.168.0.104.56799: 38560 2/0/0 A 207.46.197.32, A 207.46.232.182 (63)

    2) A "dscacheutil -q host -a name dell.com." queries the specified name servers in REVERSE order as shown by the SIGINFO dump from mDNSResponder:

    03:08:45.999752 IP 192.168.0.104.52265 > 208.67.220.220.53: 51153+ AAAA? dell.com. (26)
    03:08:46.113500 IP 208.67.220.220.53 > 192.168.0.104.52265: 51153 0/0/0 (26)
    03:08:46.448882 IP 192.168.0.104.65288 > 208.67.220.220.53: 44627+ A? dell.com. (26)
    03:08:46.510262 IP 208.67.220.220.53 > 192.168.0.104.65288: 44627 2/0/0 A 143.166.83.38, A 143.166.224.244 (58)

    Both sets of queries should have been made to 208.67.222.222.


    I'll let you whether they have anything to add.
  • Barnski Level 1 Level 1 (0 points)
    Good work William - thanks for that. I have also registered the problem at the feedback page -> http://www.apple.com/feedback/macosx.html

    Keep us posted on progress, if you hear anything.
  • William Kucharski Level 6 Level 6 (14,890 points)
    Will do.

    The frustrating thing is that it's intermittent - the order of the nameservers seems to change - so I'm wondering if it's Apple's attempt to do some load balancing between DNS servers by switching off every so often.
  • Statman1 Level 1 Level 1 (5 points)
    Well, this may be my issue as well...will keep watching for updates...
  • Chingachgook Level 1 Level 1 (0 points)
    Many Thanks for tracking this down and getting it in front of Apple, William and Barnski. I submitted a 'me too' on feedback and cited the RADAR number.

    Does anyone know if this made it into 10.6.1? It wasn't listed as a corrected issue.

    I've installed 10.6.1 this morning. I should know within a couple of hours. So far, so good. If Entourage stays connected to Exchange all day today then I'll assume it's been fixed. It has normally been going into a disconnected state within anything from 20 minutes to 2 hours.
  • JohnDCCIU Level 1 Level 1 (15 points)
    Chingachgook wrote:
    Does anyone know if this made it into 10.6.1? It wasn't listed as a corrected issue.

    I've installed 10.6.1 this morning. I should know within a couple of hours. So far, so good. If Entourage stays connected to Exchange all day today then I'll assume it's been fixed. It has normally been going into a disconnected state within anything from 20 minutes to 2 hours.


    My testing last night and this morning show the same bug is present in 10.6.1, unfortunately.
  • William Kucharski Level 6 Level 6 (14,890 points)
    I'm also not sure at this point whether it will be considered a bug or a feature as the same functionality is available in BIND >= 8.2 by specifying the "rotate" keyword in /etc/resolv.conf, so there is a precedent.

    I don't want to speculate, though, so all I can say is I'll let you know if and when I'm contacted.
  • Barnski Level 1 Level 1 (0 points)
    Sorry all, but I just installed 10.6.1 on a laptop here, and the problem still seems to be present

    Can anyone else confirm?
  • William Kucharski Level 6 Level 6 (14,890 points)
    Yes, read above.

    Nothing in 10.6.1 changed name resolution at all, and wasn't supposed to, according to the release notes.

    At present Apple has not yet confirmed or denied whether the issues we're seeing is in fact a bug or a design decision done to perform the equivalent of the BIND "rotate" functionality.
  • Chingachgook Level 1 Level 1 (0 points)
    Yep - still there. Still have to run a +sudo killall mDNSResponder+ from time to time.

    I hope Apple either fixes or modifies the implementation so that the issue goes away. I don't relish the idea of trying to get our IT support bunch to modify the internal DNS to make it work with rotating DNS server use instead of cascading DNS server use. Add to that the fact that I'm the only Mac user on the internal network and it's not really supported. Could turn into an exercise in frustration.

    On the other side, switching to a different DNS server on the client side every once in a while when all name resolution requests are being reasonably handled seems a useless 'feature' IMHO.

    I'll watch this space.
Previous 1 3 4 5 6 7 Next