Skip navigation

Some CNAME DNS queries fail after latest 10.6.5 update

8404 Views 13 Replies Latest reply: Jan 16, 2011 10:52 PM by Mark2425 RSS
TexAIR Calculating status...
Currently Being Moderated
Nov 11, 2010 9:35 PM
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.
Server: 192.168.0.14
Address: 192.168.0.14#53

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

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 (192.168.0.12): 56 data bytes
64 bytes from 192.168.0.12: icmp_seq=0 ttl=64 time=2.818 ms
64 bytes from 192.168.0.12: icmp_seq=1 ttl=64 time=2.211 ms
64 bytes from 192.168.0.12: icmp_seq=2 ttl=64 time=1.425 ms
64 bytes from 192.168.0.12: icmp_seq=3 ttl=64 time=2.242 ms
64 bytes from 192.168.0.12: icmp_seq=4 ttl=64 time=4.882 ms
64 bytes from 192.168.0.12: icmp_seq=5 ttl=64 time=3.190 ms
^C
--- 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 Calculating status...
    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:

    http://support.apple.com/kb/HT3473

    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.
    Mac OS X (10.6.5)
  • andyBall_uk Level 6 Level 6 (17,470 points)
    Currently Being Moderated
    Nov 12, 2010 10:04 AM (in response to TexAIR)
    http://bugreport.apple.com for starters - apple don't necessarily check here.
  • danparker Calculating status...
    Currently Being Moderated
    Nov 12, 2010 12:46 PM (in response to TexAIR)
    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.
    Mac OS X (10.6.5)
  • andyBall_uk Level 6 Level 6 (17,470 points)
    Currently Being Moderated
    Nov 12, 2010 12:54 PM (in response to TexAIR)
    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 Calculating status...
    Currently Being Moderated
    Nov 29, 2010 10:16 AM (in response to TexAIR)
    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.
    MacBook Pro 17 (6,1), Mac OS X (10.6.5), iPhone 4
  • KevinP.FTS Level 1 Level 1 (0 points)
    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.
    MacBook Pro 17 (6,1), Mac OS X (10.6.5), iPhone 4
  • William Kucharski Level 6 Level 6 (14,395 points)
    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:

    LOGGING
    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.
    15" 2.6 GHz MBP Penryn, 4 GB | 64GB 3G iPad | 1 TB Dual-Band TC, Mac OS X (10.6.5)
  • danparker Level 1 Level 1 (0 points)
    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?
    MBP, Mac OS X (10.6)
  • Mark2425 Calculating status...
    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 (192.168.1.14): 56 data bytes
    64 bytes from 192.168.1.14: icmp_seq=0 ttl=64 time=0.401 ms
    64 bytes from 192.168.1.14: icmp_seq=1 ttl=64 time=0.253 ms
    64 bytes from 192.168.1.14: icmp_seq=2 ttl=64 time=0.387 ms
    64 bytes from 192.168.1.14: icmp_seq=3 ttl=64 time=0.296 ms
    ^C
    --- 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
    Server: 192.168.1.10
    Address: 192.168.1.10#53

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

    {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
    Powerbook, MacPro, Mac OS X (10.6.6)
  • Mark2425 Level 1 Level 1 (0 points)
    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.
    Powerbook, MacPro, Mac OS X (10.6.6)

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.