dns - Configuring etc/hostname

06
2014-04
  • Bartlomiej Lewandowski

    I just received my Raspberry Pi, and wanted to set up a small webserver.

    I am not sure what to put as my hostname. I have bought a domain, for the sake of the question, let's assume it's mydomain.com.

    I first tried setting the hostname to webserver, so that my fully qualified name would be webserver.mydomain.com. But I read that the hostname should be in DNS. So my second thought is to set this to mydomain. Am I correct in this assumption?

    • Answers
  • Ilja

    if you're holding Raspberry Pi in your hands then you're lucky man. If you've already registered you domain as mydomain.com, so there is no problem to set hostname as server.mydomain.com or webserver.mydomain.com. If your server will works directly with internet then you need to set WAN IP address on it and configure A record in your domain control panel, say:

    webserver.mydomain.com  A XXX.XX.XXX.XX

    If you will lease a private IP address then you need to look at Dynamic DNS

    If you will use your webserver in private mode and want to ssh to it via FQDN then you need setup your hosts file at your PC


    • Related Question

    networking - Why is my wireless router screwing up hostname lookups?
  • Austin Hyde

    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.


    • Related Answers
  • KCotreau

    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.

  • billc.cn

    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.