Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Some CNAME DNS queries fail after latest 10.6.5 update

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

Posted on Nov 11, 2010 9:35 PM

Reply
13 replies

Nov 12, 2010 2:45 AM in response to TexAIR

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.

Nov 12, 2010 3:50 AM in response to dredshaw

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 (192.168.0.12): 56 data bytes
64 bytes from 192.168.0.12: 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.

Thanks,
Pedro

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.

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.

Nov 29, 2010 12:44 PM in response to KevinP.FTS

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.

Nov 29, 2010 10:27 PM in response to KevinP.FTS

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.

Jan 16, 2011 10:44 PM in response to danparker

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

Some CNAME DNS queries fail after latest 10.6.5 update

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.