DNS issues in Lion

kLy · Jul 6, 2011

Using the GM here and seems like there's some issues with the DNS, specifically the search domain only takes 1 level of subdomains.

So if you have your domain set as: company.com

You can do:

Code:

ping project1

which then resolves to project1.company.com

This works. However if you do this:

Code:

ping forum.project1

this does not resolve to forum.project1.company.com

Technically it should, and it did in previous versions of OS X, but not in Lion.

This is a bit problematic as there are a ton of links being sent back and forth in our company in the form of: http://forum.project1/index.php which then does not resolve to the correct address.

Anyone know if there's some config than can be done to work around this?

Thx

jr195 · Jul 22, 2011

same problem

Installed the official release and having the same problem.

anybody find a fix/workaround?

mrapplegate · Jul 22, 2011

I can ping forums.macrumors.com, and macrumors.com as an example. Both resolve to different IPs.
Please give us actual domain names to test. Is this internal only?
DNS is pretty standard and most mistakes are in the setup on the company end.

PING macrumors.com (173.192.108.135): 56 data bytes
64 bytes from 173.192.108.135: icmp_seq=0 ttl=53 time=45.656 ms
64 bytes from 173.192.108.135: icmp_seq=1 ttl=53 time=156.183 ms
64 bytes from 173.192.108.135: icmp_seq=2 ttl=53 time=56.626 ms
64 bytes from 173.192.108.135: icmp_seq=3 ttl=53 time=170.322 ms

PING forums.macrumors.com (173.192.108.232): 56 data bytes
64 bytes from 173.192.108.232: icmp_seq=0 ttl=53 time=81.188 ms
64 bytes from 173.192.108.232: icmp_seq=1 ttl=53 time=43.375 ms
64 bytes from 173.192.108.232: icmp_seq=2 ttl=53 time=81.330 ms

synfinatic · Jul 22, 2011

mrapplegate said:
I can ping forums.macrumors.com, and macrumors.com as an example. Both resolve to different IPs.
Please give us actual domain names to test. Is this internal only?
DNS is pretty standard and most mistakes are in the setup on the company end.

PING macrumors.com (173.192.108.135): 56 data bytes
64 bytes from 173.192.108.135: icmp_seq=0 ttl=53 time=45.656 ms
64 bytes from 173.192.108.135: icmp_seq=1 ttl=53 time=156.183 ms
64 bytes from 173.192.108.135: icmp_seq=2 ttl=53 time=56.626 ms
64 bytes from 173.192.108.135: icmp_seq=3 ttl=53 time=170.322 ms

PING forums.macrumors.com (173.192.108.232): 56 data bytes
64 bytes from 173.192.108.232: icmp_seq=0 ttl=53 time=81.188 ms
64 bytes from 173.192.108.232: icmp_seq=1 ttl=53 time=43.375 ms
64 bytes from 173.192.108.232: icmp_seq=2 ttl=53 time=81.330 ms

I don't think the test you did above is correct.

The problem is when you have sub domains like subdomain.domain.com and in your search path just put domain.com. You *should* be able to ping host.subdomain and it will resolve it as host.subdomain.domain.com, but as of Lion this no longer works.

I didn't have a public subdomain, so I just created one. May take a while to fully propagate, but ns1.linode.com is authoritative (69.93.127.10) and should work right now.

If you make synfin.net your search path you should be able to ping:

http://www.synfin.net
www
http://www.sub.synfin.net
http://www.sub

However, this bug prevents "www.sub" from resolving to http://www.sub.synfin.net. It works fine with the "host" command, but tools like ping/ssh fail (I believe because they use the gethostbyname() call while host purely uses dns). This worked just fine in previous versions of OSX and broke in Lion.

mrapplegate · Jul 22, 2011

synfinatic said:
I don't think the test you did above is correct.

The problem is when you have sub domains like subdomain.domain.com and in your search path just put domain.com. You *should* be able to ping host.subdomain and it will resolve it as host.subdomain.domain.com, but as of Lion this no longer works.

I didn't have a public subdomain, so I just created one. May take a while to fully propagate, but ns1.linode.com is authoritative (69.93.127.10) and should work right now.

If you make synfin.net your search path you should be able to ping:

http://www.synfin.net
www
http://www.sub.synfin.net
http://www.sub

However, this bug prevents "www.sub" from resolving to http://www.sub.synfin.net. It works fine with the "host" command, but tools like ping/ssh fail (I believe because they use the gethostbyname() call while host purely uses dns). This worked just fine in previous versions of OSX and broke in Lion.

http://www.sub is not a fully qualified domain name, same with www, so how can it resolve to anything? I can test pings for the other domains.

PING http://www.synfin.net (69.164.195.87): 56 data bytes
64 bytes from 69.164.195.87: icmp_seq=0 ttl=51 time=450.602 ms
64 bytes from 69.164.195.87: icmp_seq=1 ttl=51 time=269.812 ms
64 bytes from 69.164.195.87: icmp_seq=2 ttl=51 time=449.045 ms
64 bytes from 69.164.195.87: icmp_seq=3 ttl=51 time=270.341 ms

PING http://www.sub.synfin.net (69.164.195.87): 56 data bytes
64 bytes from 69.164.195.87: icmp_seq=0 ttl=51 time=104.575 ms
64 bytes from 69.164.195.87: icmp_seq=1 ttl=51 time=79.892 ms
64 bytes from 69.164.195.87: icmp_seq=2 ttl=51 time=109.342 ms

I'm not really seeing your problem. I'm testing this via Network Utility in Lion and it works in terminal as well.

synfinatic · Jul 22, 2011

mrapplegate said:
http://www.sub is not a fully qualified domain name, same with www, so how can it resolve to anything? I can test pings for the other domains.

....

I'm not really seeing your problem. I'm testing this via Network Utility in Lion and it works in terminal as well.

Well that's what the "search synfin.net" line in the resolv.conf is for. You can have multiple domain/subdomains listed on the search line and when you type a name it will append each of them in order to see if it resolves. At least that's how it's supposed to work and did until Lion.

mrapplegate · Jul 22, 2011

synfinatic said:
Well that's what the "search synfin.net" line in the resolv.conf is for. You can have multiple domain/subdomains listed on the search line and when you type a name it will append each of them in order to see if it resolves. At least that's how it's supposed to work and did until Lion.

Perhaps you don't understand DNS. Do you think everyone on the internet is supposed to add lines to resolve.conf to resolve domains you make?
I don't know what to tell you. You can't resolve www or http://www.sub because they are NOT FULLY QUALIFIED domain names. These will never resolve to anything in the public. They might for a private network.

synfinatic · Jul 22, 2011

mrapplegate said:
Perhaps you don't understand DNS. Do you think everyone on the internet is supposed to add lines to resolve.conf to resolve domains you make?
I don't know what to tell you. You can't resolve www or http://www.sub because they are NOT FULLY QUALIFIED domain names. These will never resolve to anything in the public. They might for a private network.

Uh, you asked for an example domain so I created an external one for you to test. I'm not going to expose my internal DNS for you.

Yes, nobody does this for external domains. But where I work we have over 100 subdomains (one for each location) and typing:

ping host.location

is a lot better then:

ping host.location.internal.company.com

And this used to work just fine because my /etc/resolv.conf had the line:

search company.com internal.company.com
\

mrapplegate · Jul 22, 2011

synfinatic said:
Uh, you asked for an example domain so I created an external one for you to test. I'm not going to expose my internal DNS for you.

Yes, nobody does this for external domains. But where I work we have over 100 subdomains (one for each location) and typing:

ping host.location

is a lot better then:

ping host.location.internal.company.com

And this used to work just fine because my /etc/resolv.conf had the line:

search company.com internal.company.com
\

I'm only going by what you post. You state that you could not ping www or other subdomains. I understand you can't give me access to your internal DNS. Your post did not mention this being on a private network. There are a lot of variables that come into play when DNS is involved. A major clue that it is user error is when someone says http://www.sub does not resolve. Without seeing the actual DNS setup there is not much we can do. The fact that I showed Lion can ping subdomains with forums.macrumors.com vs macrumors.com shows there is not a problem with how Lion handles DNS, but a problem with your DNS setup.

synfinatic · Jul 22, 2011

mrapplegate said:
I'm only going by what you post. You state that you could not ping www or other subdomains. I understand you can't give me access to your internal DNS. Your post did not mention this being on a private network. There are a lot of variables that come into play when DNS is involved. A major clue that it is user error is when someone says http://www.sub does not resolve. Without seeing the actual DNS setup there is not much we can do. The fact that I showed Lion can ping subdomains with forums.macrumors.com vs macrumors.com shows there is not a problem with how Lion handles DNS, but a problem with your DNS setup.

Sorry, I thought I was being clear when I wrote:

synfinatic said:
I didn't have a public subdomain, so I just created one. May take a while to fully propagate, but ns1.linode.com is authoritative (69.93.127.10) and should work right now.

As for your test, your test is testing something different then what I'm talking about. You're using the FQDN's so the resolver is never having to iterate over the search list because that's always tested first.

Just edit your /etc/resolv.conf:

search synfin.net
nameserver 69.93.127.10

Trying pinging from the command line (I never use the GUI, I don't know if it has the same issue):

http://www.synfin.net
www
http://www.sub.synfin.net
http://www.sub

Then use the "host" command for the above four items. Notice that "host" resolves them all, but ping complains it can't resolve http://www.sub.

Trust me, it's a valid config. My company has been doing this for over a decade with just about every version of Linux, Free/Net/OpenBSD and Solaris and it works fine. It's worked fine in OSX until Lion.

I'm know I'm new here to macrumors, but trust me when I say I know networking and I know it's not a problem with our DNS config.

mrapplegate · Jul 22, 2011

synfinatic said:
Sorry, I thought I was being clear when I wrote:

As for your test, your test is testing something different then what I'm talking about. You're using the FQDN's so the resolver is never having to iterate over the search list because that's always tested first.

Just edit your /etc/resolv.conf:

search synfin.net
nameserver 69.93.127.10

Trying pinging from the command line (I never use the GUI, I don't know if it has the same issue):

http://www.synfin.net
www
http://www.sub.synfin.net
http://www.sub

Then use the "host" command for the above four items. Notice that "host" resolves them all, but ping complains it can't resolve http://www.sub.

Trust me, it's a valid config. My company has been doing this for over a decade with just about every version of Linux, Free/Net/OpenBSD and Solaris and it works fine. It's worked fine in OSX until Lion.

I'm know I'm new here to macrumors, but trust me when I say I know networking and I know it's not a problem with our DNS config.

I'm still not seeing a valid IP address for www or http://www.sub using your name server 69.93.127.10.

Default server: 69.93.127.10
Address: 69.93.127.10#53
> http://www.synfin.net
Server: 69.93.127.10
Address: 69.93.127.10#53

Name: http://www.synfin.net
Address: 69.164.195.87
>
> www
Server: 69.93.127.10
Address: 69.93.127.10#53

** server can't find www: REFUSED
>

> http://www.sub.synfin.net
Server: 69.93.127.10
Address: 69.93.127.10#53

If this works in SL and not in Lion, then you should not upgrade.

synfinatic · Jul 22, 2011

mrapplegate said:
I'm still not seeing a valid IP address for www or http://www.sub using your name server 69.93.127.10.

Default server: 69.93.127.10
Address: 69.93.127.10#53
> http://www.synfin.net
Server: 69.93.127.10
Address: 69.93.127.10#53

Name: http://www.synfin.net
Address: 69.164.195.87
>
> www
Server: 69.93.127.10
Address: 69.93.127.10#53

** server can't find www: REFUSED
>

> http://www.sub.synfin.net
Server: 69.93.127.10
Address: 69.93.127.10#53

If this works in SL and not in Lion, then you should not upgrade.

Too late for that.

That output doesn't look like ping or host... more like nslookup? ping uses gethostbyname(), but I'm pretty sure host and nslookup don't. Perhaps you didn't set your search domain properly? If you do, then both www and http://www.sub work:

Code:

$ nslookup -  69.93.127.10
> set domain=synfin.net
> www
Server:         69.93.127.10
Address:        69.93.127.10#53

Name:   www.synfin.net
Address: 69.164.195.87
> www.sub
Server:         69.93.127.10
Address:        69.93.127.10#53

Name:   www.sub.synfin.net
Address: 69.164.195.87

mrapplegate · Jul 22, 2011

synfinatic said:
Too late for that.

That output doesn't look like ping or host... more like nslookup? ping uses gethostbyname(), but I'm pretty sure host and nslookup don't. Perhaps you didn't set your search domain properly? If you do, then both www and http://www.sub work:

Code:

$ nslookup - 69.93.127.10 > set domain=synfin.net > www Server: 69.93.127.10 Address: 69.93.127.10#53 Name: www.synfin.net Address: 69.164.195.87 > www.sub Server: 69.93.127.10 Address: 69.93.127.10#53 Name: www.sub.synfin.net Address: 69.164.195.87

Correct I set the server with Server then the IP you gave.
Did you really migrate a company computer to Lion without testing?

mrapplegate · Jul 22, 2011

I don't know what else to say, I have tried to help. I'm not seeing a DNS issue in Lion. If someone else can chime in and help.

synfinatic · Jul 22, 2011

mrapplegate said:
I don't know what else to say, I have tried to help. I'm not seeing a DNS issue in Lion. If someone else can chime in and help.

You're getting REFUSED because you didn't set your search path in nslookup. You have to run the command in nslookup:

set domain=synfin.net

and THEN query for www and http://www.sub. Without setting the search path, you've effectively requested the TLD "www" which that dns server is not authoritative for and it doesn't do recursive lookups.

jwoolard · Jul 25, 2011

I'm seeing the same issue as synfinatic (in my case, this is a config picked up automatically from a VPN connection that works perfectly for a number of Linux, windows and BSD clients).

This functionality is VERY widely used in private networks - I'm sure we're not the only ones seeing this. What is the right way to get in touch with Apple?

synfinatic · Jul 25, 2011

jwoolard said:
I'm seeing the same issue as synfinatic (in my case, this is a config picked up automatically from a VPN connection that works perfectly for a number of Linux, windows and BSD clients).

This functionality is VERY widely used in private networks - I'm sure we're not the only ones seeing this. What is the right way to get in touch with Apple?

If you have an ADC account (I got mine free a few years ago) you can open a bug here: https://bugreport.apple.com/. That's what I did. The ticket (Problem Id) is 9828990. The more people who open a bug report with Apple, the more likely they will fix it soon.

kkircher · Jul 25, 2011

Answer to the problem

I too had this problem, and I put in a bug with apple. Here is their response. The work around worked for myself and co-workers. Don't really accept their answer, but oh well.

I have received a response from engineering. The behavior observed in Lion clients is expected behavior. It is working as intended.

The only workaround is to edit the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist file.
Unfortunately, it is outside of AppleCare's support agreements to assist with an edit to such a file.
However, if you are comfortable editing the .plist yourself, or know someone who can, here is what needs to be modified:

<key>ProgramArguments</key>
<array>
<string>/usr/sbin/mDNSResponder</string>
<string>-launchd</string>
<string>-AlwaysAppendSearchDomains</string>
</array>

You must also restart the machine in order for it to take effect.

synfinatic · Jul 25, 2011

Thanks for that info. I'll definitely give it a try. Seriously though Apple, wtf?

kLy · Aug 1, 2011

The behavior observed in Lion clients is expected behavior.

Wha? We have hundreds of machines here on our internal network of every flavour... Windows, Linux, BSD, OS X (pre-10.7), and none of them afaict do this, so I really don't see how this is expected behaviour

Thanks for letting us know about the AlwaysAppendSearchDomains, kkircher. I'll try that out... hopefully it doesn't do strange things like try append them on to google.com.

ryanarr · Apr 17, 2013

Sorry to ressurect an old thread, but since this seems to be the only place on the internet this question had been adequately addressed, I'd like to update this thread with a quick command to do this without using a text editor or rebooting:

Code:

sudo defaults write /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist ProgramArguments -array-add "-AlwaysAppendSearchDomains"
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

synfinatic · Apr 17, 2013

Very cool! Thanks for sharing!

DNS issues in Lion

macrumors newbie

macrumors newbie

macrumors 68030

macrumors newbie

macrumors 68030

macrumors newbie

macrumors 68030

macrumors newbie

macrumors 68030

macrumors newbie

macrumors 68030

macrumors newbie

macrumors 68030

macrumors 68030

macrumors newbie

macrumors newbie

macrumors newbie

macrumors newbie

macrumors newbie

macrumors newbie

macrumors newbie

macrumors newbie

Our Staff