13 Replies Latest reply: Jan 16, 2011 10:52 PM by Mark2425
TexAIR Level 1 Level 1
Right after rebooting from the latest MacOS X update I noticed some DNS queries are failing. These happen to be DNS queries for CNAME records. Other computers in the same network are not affected by this problem, including Mac's to wich the update was not yet installed.

Here are the simple diagnostic steps:

snowboard:~ pmsjt$ nslookup imap.texair.net.

imap.texair.net canonical name = taz.warner.local.
Name: taz.warner.local

snowboard:~ pmsjt$ ping imap.texair.net
ping: cannot resolve imap.texair.net: Unknown host
snowboard:~ pmsjt$

snowboard:~ pmsjt$ ping taz.warner.local
PING taz.warner.local ( 56 data bytes
64 bytes from icmp_seq=0 ttl=64 time=2.818 ms
64 bytes from icmp_seq=1 ttl=64 time=2.211 ms
64 bytes from icmp_seq=2 ttl=64 time=1.425 ms
64 bytes from icmp_seq=3 ttl=64 time=2.242 ms
64 bytes from icmp_seq=4 ttl=64 time=4.882 ms
64 bytes from icmp_seq=5 ttl=64 time=3.190 ms
--- taz.warner.local ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.425/2.795/4.882/1.083 ms
snowboard:~ pmsjt$

MacBook, Mac OS X (10.6.5), Core 2 Duo 2.4GHz, 4GB RAM
  • dredshaw Level 1 Level 1
    I think Apple has changed the way .local lookups work. Many companies use companyname.local for internal Active Directory domains and then point records in their registered domain (e.g. company.com) to the .local machine name.

    For example:

    website.company.com => CNAME webserver.companyname.local

    According to this article:


    The OS should use unicast DNS to look up the .local host above because there are two segments to the name in addition to .local. It appears however that this is not the case. The system does in fact use mDNS to look up the .local name (in my case it uses unicast DNS to lookup the .com record and then uses mDNS to lookup the .local record).

    I'm sure there's a better fix, but for a couple of hosts changing the CNAME records to A records should fix it.
  • TexAIR Level 1 Level 1
    Hi dredshaw,

    Your logic does make sense. This might be somehow related to the problem. However...

    snowboard:~ pmsjt$ ping taz.warner.local
    PING taz.warner.local ( 56 data bytes
    64 bytes from icmp_seq=0 ttl=64 time=2.818 ms

    ... works.

    If the *.warner.local lookup was being performed consistently (tho wrong) by mDNS, this second test would fail too. It seems to only affect when there is a CNAME leading into the (...).local.

    Don't want to jump the gun here, but the inconsistent behavior clues a bug rather than a design decision.

  • TexAIR Level 1 Level 1
    If this is really an issue with the latest update, what is the best channel to report it to Apple? Is this forum good enough, or should I try a direct contact with the product support?

    Anyone with experience in this coarse of action?

  • andyBall_uk Level 7 Level 7
    http://bugreport.apple.com for starters - apple don't necessarily check here.
  • TexAIR Level 1 Level 1
    Hum... this requires a registered developer... Doesn't that imply accepting draconian disclosure agreements that may conflict with your job?
  • danparker Level 1 Level 1
    Worth mentioning that I am also having this problem. I don't have anything to add other than a it's on every 10.6.5 machine I've been able to find and not just my managed clients. It only occurs after the 10.6.5 update.

    What's truly interesting is that dig, nslookup and host all work correctly but I cannot ping or traceroute some CNAME's to multiple servers. Additionally, the only .local CNAME is the only one that works. FQDN and IP are fine on 10.6.5. Additionally, every other platform is fine as well as 10.6.4 Macs.

    I'm open to any suggestions or things to try. I've reapplied the standalone update and subsequently applied the Combo Update. The problem persists and has stumped a number of folks that I've bounced it off of.

    Thanks for everyone's time.
  • andyBall_uk Level 7 Level 7
    Hum... this requires a registered developer... Doesn't that imply accepting draconian disclosure >agreements that may conflict with your job?

    Quite right - try http://www.openradar.me/ instead.
  • KevinP.FTS Level 1 Level 1
    I am experiencing the same issues re: unable to connect to a server via its CNAME record pointing, a FQDN (server1.ourdomainname.NET), internally to an A record. I can look up the information and see the A record and IP to which this ".net" zone CNAME points, but I can't ping it.

    Strangely, we have another CNAME record for "server1.ourdomainname.LOCAL" that points to the CNAME "server1.ourdomainname.NET" (the one I can't reach internally), and THAT one resolves fine. But it doesn't help when it's our mail server and I need to be able to access both on and off site.

    THIS IS NOT LIMITED TO MACS. Our iPhones AND iPads are experiencing the exact same behavior. I.E., they can reach the FQDN externally, but not internally. This all happened about the same time.

    Windows clients are unaffected by this one DNS oddity on our network. Even my Windows 7 VM on my Mac can resolve the FQDN fine internally.
  • KevinP.FTS Level 1 Level 1
    Changing our "server1.ourdomainname.NET" from a CNAME record to an A record worked to fix our Mac, iPhone, and iPad access issues for the problem server name.

    As I tested further, I discovered that CNAMEs in the "ourdomainname.LOCAL" zone work fine, and CNAMEs in the "ourdomainname.NET" zone work fine, too, so long as the are pointing to A records that are also in the "ourdomainname.NET" zone (or a subdomain of that zone). HOWEVER, for ALL our records that are CNAMEs in the "x.LOCAL" zone that point to records in the "x.NET" zone, I can see the CNAME and corresponding IPs via nslookup, but I cannot reach them (via ping or traceroute or anything).

    This seems to me to be related to the whole ".local" issue with Apple devices using the Bonjour service, at least in my guestimation (and I don't have time to research further today).

    A records fix this. Not mixing external and internal zones also fixes this, at least in my environment. It's still a pain.
  • William Kucharski Level 6 Level 6
    Mac OS X
    Just as a sanity check, the second portion of the clause from the KB article doesn't apply in your situation, does it?

    Additionally, Mac OS X v10.6 automatically detects when the local network operator has set up a name server that will answer name requests for a domain ending in ".local". It does this by checking to see if there is a Start Of Authority (SOA) record for the top level domain "local", which is how a DNS server indicates that it claims to have authority over a part of the DNS namespace. As long as the DNS server is properly configured with the required SOA record, Mac OS X v10.6 will detect this SOA record and automatically use this server to look up all host names in the domain.

    Also, if you have time, you might want to check what mDNSResponder is actually doing by enabling logging; the man page describes the process in more detail:

    There are several methods with which to examine mDNSResponder's internal state for debugging and
    diagnostic purposes. The syslog(1) logging levels map as follows:

    Error - Error messages
    Warning - Client-initiated operations
    Notice - Sleep proxy operations
    Info - Informational messages

    By default, only log level Error is logged.

    A SIGUSR1 signal toggles additional logging, with Warning and Notice enabled by default:

    % sudo killall -USR1 mDNSResponder

    Once this logging is enabled, users can additionally use syslog(1) to change the log filter for the
    process. For example, to enable log levels Emergency - Debug:

    % sudo syslog -c mDNSResponder -d

    A SIGUSR2 signal toggles packet logging:

    % sudo killall -USR2 mDNSResponder

    A SIGINFO signal will dump a snapshot summary of the internal state to /var/log/system.log:

    % sudo killall -INFO mDNSResponder

    http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/ man8/mDNSResponder.8.html

    I suspect in this case packet logging might be most informative.
  • danparker Level 1 Level 1
    This appears to be resolved in 10.6.6 on the 2 machines that I've upgraded so far. Can anyone else experiencing the issue confirm?
  • Mark2425 Level 1 Level 1
    I'm running 10.6.6 and I'm seeing the same behavior:

    {63} [Mon Jan 17][mgweber@io ~] -> ping atlas.home.lan
    PING atlas.home.lan ( 56 data bytes
    64 bytes from icmp_seq=0 ttl=64 time=0.401 ms
    64 bytes from icmp_seq=1 ttl=64 time=0.253 ms
    64 bytes from icmp_seq=2 ttl=64 time=0.387 ms
    64 bytes from icmp_seq=3 ttl=64 time=0.296 ms
    --- atlas.home.lan ping statistics ---
    4 packets transmitted, 4 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 0.253/0.334/0.401/0.062 ms
    {64} [Mon Jan 17][mgweber@io ~] -> nslookup files.home.lan

    files.home.lan canonical name = atlas.home.lan.
    Name: atlas.home.lan

    {65} [Mon Jan 17][mgweber@io ~] -> ping files.home.lan
    ping: cannot resolve files.home.lan: Unknown host

    using BIND 30:9.3.6-4.P1.el5_5.3
  • Mark2425 Level 1 Level 1
    scratch that... a reboot fixed the issue. I added the files CNAME entry, restarted named, and assumed everything would resolve. didn't. files.home.lan resolves now.