1

The problem: I have two computers on my wireless network (domain name "serenity", at 192.168.1.1), hostnames "jayne" (Arch Linux, at 192.168.1.108), and "mal" (Mac OS X, at 192.168.1.101). When I try to get the two to communicate, this happens:

jayne$ ping mal
PING mal.serenity (184.106.31.161) ... [pings go through to weird IP]

and

mal$ ping jayne
PING jayne.serenity (184.106.31.161) ...

However, pinging the router works:

jayne or mal$ ping serenity
PING serenity.serenity (192.168.1.1) ...

And then things get weird:

jayne or mal$ ping google
PING google.serenity (184.106.31.161) ... [same IP as before]

jayne or mal$ ping google.com
PING google.com (74.125.115.106) ... [works as expected]

jayne$ ping 192.168.1.101
PING  192.168.1.101 (192.168.1.101) ... [works as expected]

So why can't mal or jayne see each other?

The catch: serenity is currently connected to another, pre-existing router (it doesn't have a domain name) which is the primary gateway to the internet, located at 192.168.0.1. I set up a static DHCP rule to always map serenity to 192.168.0.2.

Now, I noticed that when I go to a non-existent URL in my browser, I get redirected to my ISP's "Search the internet for *" page, so I figured the weird IP addresses the pings were resolving to probably belonged to whatever server handled that on the ISP, and changed the DNS servers on the .0.1 router to Google's Public DNS service.

Now, ping mal or ping jayne don't resolve at all ("ping: unknown host mal", "ping: cannot resolve jayne: Unknown host"), even with "full" names (like "mal.serenity"), but I can still successfully ping serenity.

So why can't mal or jayne see each other?

I'm not really a network-y guy, so I probably just have a setting wrong somewhere, but in the mean time I'm using hosts files to get around this, by manually mapping the host names to IP addresses, but that's just fixing the symptom, not the problem.

3
  • Is 184.106.31.161, your external IP if you go to whatismyip.com?
    – KCotreau
    Jul 26, 2011 at 4:37
  • no in-addr.arpa entry for that IP range, but it is a Texas IP. Chances are that is your public IP, which would not be abnormal. Can you post the full ping results from each of those examples and not just the beginning?
    – MaQleod
    Jul 26, 2011 at 5:02
  • I have double checked, and 184.106.31.161 is not my public IP address. That is in 24.*. I'll be able to provide full ping results later this evening, but there's nothing unusual about them other than the IP address is not one I was expecting. Jul 26, 2011 at 12:47

2 Answers 2

2

I may amend or delete this based on your answer to the above comment/question.

This is what I believe is going on, and it may help you some. The first part is easy: You are trying to use DNS to ping workstations that are not registered in DNS anywhere, and your router/DNS server is returning its external IP address (I believe, and your answer to the question above will confirm this).

The second part is that if you compare two Windows workstations, when they don't register to a local DNS server, they use NetBIOS over TCP/IP to find each other. In your case, I am not sure if you have anything similar you can use as I am not a Linux or Mac guy, and if yo do, it is not currently in use.

What I can say is that you could set up your Linux box to act as a DNS server, host your own DNS, and register your computers with that server; or you can simply continue to use HOSTS files. Lastly, someone very likely may come along and add another answer that tells you how to let Linux and Macs communicate without using DNS, similar to NetBIOS over TCP/IP.

If someone does not come along with something similar to the NetBIOS over TCP/IP concept, then my personal opinion is that you are fine with using HOSTS files, and that is the way to go.

4
  • I would give the same answer. It's clear that both computers are trying to resolve through an external DNS. Either turn on NetBIOS, setup a DNS server, or setup your router to keep .serenity resolutions private.
    – surfasb
    Jul 26, 2011 at 12:47
  • I have verified that the 184.106.31.161 address is not my public IP address. That being said, the rest makes sense. I was lead to believe that the router functioned as a kind of DNS pit-stop, and any connected hosts would register their names with the router, which would then do the mapping based on connected hostnames. Jul 26, 2011 at 12:51
  • @surfasb Do OS X and Linux have NetBIOS capability? I looked for that, but did not seem to find in the affirmative. Even if serenity can keep DNS private, most of those router DNS servers cannot take registrations.
    – KCotreau
    Jul 26, 2011 at 12:52
  • Yeah, they both have NetBIOS capability. I'll have to google and find out how to turn it on.
    – surfasb
    Jul 26, 2011 at 13:02
0

The ".serenity" bit might have been appended as a DNS search domain. This can be automatically configured via DHCP so that's probably where you are getting it from. In your router's DHCP settings clear all search domain fields (if any).

If you still see it, under Windows, go to your TCP/IP settings, click "Advanced" and under the DNS tab:

  • Clear "The DNS suffix for this connection" box
  • Select "Append these DNS suffixes" and make sure nothing is in the list

You may have to do this for both IPv4 and IPv6.

On a Mac, goto Network in System Preferences. Click the Advanced button of your connection and under the DNS tab, click the + button to add a blank entry. (You should see that the bogus entry from DHCP is greyed-out so you can only remove it this way.)

On both Mac and Linux, you may also have to check /etc/resolve.conf to make sure that the search domain is not in there.


As to the mysterious DNS result, I guess it's some kind of "catch all" or "domain name correction" service your DNS provider is using. Normally they return this result for all non-exist domains so they could get some ad revenue from you. OpenDNS and many ISPs do this.

The host name appended with the search domain is no longer a valid local host name but what looks like a proper FQDN to the OS, so the latter sends it to a DNS server as opposed to consulting NetBIOS. If you don't have this "catch all" service, your OS will eventually realize this is not a proper domain and fall back to NetBIOS or other name resolution mechanism.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .