1 2 Previous Next 25 Replies Latest reply on Jun 26, 2014 5:19 AM by niksajur Go to original post
      • 16. Re: Host/domain name problem in /etc/hosts and /etc/resolv.conf
        Dude!

        I would have to look into more details, but it probably depends on what value DHCP_HOSTNAME expects, for instance the hostname, such as "proton", or the fully qualified hostname including the domain name, such as "proton.example.com". I think the correct value is just the hostname.

         

        From what I understand DHCP does not set the local machine name or change the domain name without additional software or scripting, but can update the DHCP DNS with the name given by the DHCP client and can update /etc/resolve.conf to include a search name should the DNS domain of the DHCP server be different than the domain name of the client.

         

        The dhclient-script in RHEL6 extracts the hostname from the variable, and performs a reverse lookup of the client's TCP/IP address to determine the available domain names, which are added to the search domains of the local /etc/resolv.conf file, but results may be different when using e.g. NetworkManager.

         

        [root@proton ~]# ipcalc --hostname 192.168.2.102
        HOSTNAME=proton.example.com

         

        If you have an appropriate entry in /etc/hosts, this is probably where it comes from. What happens when do the same without /etc/hosts and query your DNS nameserver (ADSL modem) instead?

        1 person found this helpful
        • 17. Re: Host/domain name problem in /etc/hosts and /etc/resolv.conf
          niksajur

          > What happens when do the same without /etc/hosts and
          > query your DNS nameserver (ADSL modem) instead?

           

          Seems that discussions like this one never end. Interesting question! Without /etc/hosts (all entries commented), and after restarting the network, this is what happens:

           

          [root@proton ~]# ipcalc --hostname 192.168.2.1
          HOSTNAME=speedport.ip

           

          [root@proton ~]# ipcalc --hostname 192.168.2.102
          HOSTNAME=proton.example.co

           

          [root@proton ~]# ipcalc --hostname 127.0.0.1
          HOSTNAME=localhost

           

          Notice "example.co" instead of "example.com". Also, "localhost" instead of "localhost.localdomain". All three addresses can be pinged (as expected), but not their corresponding host names (as also expected), except only speedport.ip (as expected). So, the host names

           

          localhost
          localhost.localdomain
          proton
          proton.example.com
          proton.example.co    (returned unexpectedly by ipcalc!!!)

           

          cannot be pinged at all.

           

          The following is even more interesting:

           

          root@proton ~]# hostname
          proton.example.com

           

          [root@proton ~]# hostname --fqdn
          proton.example.com

           

          [root@proton ~]# hostname --all-fqdns
          proton.example.co

           

          nslookup returns the same host names as ipcalc returns:

          [root@proton ~]# nslookup 192.168.2.1
          Server:         192.168.2.1
          Address:        192.168.2.1#53

           

          1.2.168.192.in-addr.arpa        name = speedport.ip.

           

          [root@proton ~]# nslookup 192.168.2.102
          Server:         192.168.2.1
          Address:        192.168.2.1#53

           

          102.2.168.192.in-addr.arpa      name = proton.example.co.

           

          [root@proton ~]# nslookup 127.0.0.1
          Server:         192.168.2.1
          Address:        192.168.2.1#53

           

          1.0.0.127.in-addr.arpa  name = localhost.

           

          The /etc/resolv.conf remains unchanged, as expected.

           

          [root@proton ~]# cat /etc/resolv.conf
          ; generated by /sbin/dhclient-script
          search Speedport_W_921V_1_34_000 example.com
          nameserver 192.168.2.1

           

          It's interesting that nslookup returns "proton.example.co" even with uncommented entries in /etc/hosts and network being restarted.

           

          Despite the fact that those outputs without /etc/hosts may look a little confusing, I don't think the entry in /etc/hosts can be the place where "example.com" comes from, nor /etc/hosts has something to do with /etc/resolv.conf. /etc/hosts is local file and, according to my experience based on experiments, you can put there whatever you want (just like I put the stupid address 10.0.0.1 after being advised by one "expert" to do so) and you will not receive any error or warning messages, either restarting the network or at the boot time. Everything will be ignored, except the appropriate entries and only those that don't interfere with each other. Without an appropriate entry, you will not be able to ping that host by its name (as you can see above), but it doesn't affect dns nameserver entry and search list in /etc/resolv.conf.

           

          Note that 30 minutes before finally solved the problem, I experimented with /etc/hosts that was the same as the actual one, restarted the network ten times, restarted the machine ten times and - NOTHING. The "localdoma" was still there. Only when I changed DHCP_HOSTNAME and restarted the machine, the problem disappeared. Unless you are believing in ghosts, this is the fact that cannot be ignored.

           

          By the way, it was not me who initially put the wrong name in DHCP_HOSTNAME. I guess it has been done by anaconda during the OL6.5 installation as the internet connection has been active all the time. Also, there is no way to customize /etc/resolv.conf manually. You can edit it, put in it whatever you want, without any effect, and on the next boot it will be overwritten by dhclient-script again (or by NetworkManager who, if enabled, takes precedence over dhclient-script). So, who did put "example.com" in /etc/resolv.conf? Obviously dhclient-script or whatever inside it (ipcalc or so). Where the information about "example.com" is coming from? There are only two places where this name resides on the system: the entry in /etc/hosts and DHCP_HOSTNAME. If it is not the entry in /etc/hosts, and I guarantee it is not, then DHCP_HOSTNAME is the only place where it comes from.

          • 18. Re: Host/domain name problem in /etc/hosts and /etc/resolv.conf
            niksajur

            Hope this may be helpful for other users on the forum with similar issues. You really help me to discover a weird item in nslookup output. Before I show it, let me resume the actual state of my network where everything works fine and correctly.

             

            [root@proton ~]# cat /etc/hosts

            127.0.0.1       localhost.localdomain localhost

            ::1             localhost6.localdomain6 localhost6

            192.168.2.102   proton.example.com proton

                

            [root@proton ~]# cat /etc/resolv.conf

            ; generated by /sbin/dhclient-script

            search Speedport_W_921V_1_34_000 example.com

            nameserver 192.168.2.1

                                 

            [root@proton ~]# hostname

            proton.example.com    

             

            [root@proton ~]# hostname --fqdn

            proton.example.com           

             

            [root@proton ~]# hostname --all-fqdns

            proton.example.com                

             

            [root@proton ~]# ipcalc --hostname 192.168.2.1

            HOSTNAME=speedport.ip                        

             

            [root@proton ~]# ipcalc --hostname 192.168.2.102

            HOSTNAME=proton.example.com                  

             

            [root@proton ~]# ipcalc --hostname 127.0.0.1

            HOSTNAME=localhost.localdomain           

             

            [root@proton ~]# ping proton

            PING proton.example.com (192.168.2.102) 56(84) bytes of data.

            64 bytes from proton.example.com (192.168.2.102): icmp_seq=1 ttl=64 time=0.041 ms

            64 bytes from proton.example.com (192.168.2.102): icmp_seq=2 ttl=64 time=0.046 ms

             

            [root@proton ~]# ping proton.example.com

            PING proton.example.com (192.168.2.102) 56(84) bytes of data.

            64 bytes from proton.example.com (192.168.2.102): icmp_seq=1 ttl=64 time=0.033 ms

            64 bytes from proton.example.com (192.168.2.102): icmp_seq=2 ttl=64 time=0.036 ms

             

            [root@proton ~]# ping localhost

            PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.

            64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.041 ms

            64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.035 ms

             

            [root@proton ~]# ping localhost.localdomain

            PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.

            64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.032 ms

            64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.037 ms

             

            [root@proton ~]# ping localhost6

            PING localhost6.localdomain6 (127.0.0.1) 56(84) bytes of data.

            64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.045 ms

            64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.037 ms

             

            [root@proton ~]# ping localhost6.localdomain6

            PING localhost6.localdomain6 (127.0.0.1) 56(84) bytes of data.

            64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.036 ms

            64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.037 ms

             

            So far, so good, even perfect. But nslookup is confusing me returning the weird host name "proton.example.co" on 192.168.2.102, although I don't bother to figure out where it is coming from. Just another host on the same address, legal and fully functional.

             

            [root@proton ~]# nslookup 192.168.2.1

            Server:         192.168.2.1

            Address:        192.168.2.1#53

             

            1.2.168.192.in-addr.arpa        name = speedport.ip.

             

            [root@proton ~]# nslookup 192.168.2.102

            Server:         192.168.2.1

            Address:        192.168.2.1#53

             

            102.2.168.192.in-addr.arpa      name = proton.example.co.

             

            [root@proton ~]# nslookup 127.0.0.1

            Server:         192.168.2.1

            Address:        192.168.2.1#53

             

            1.0.0.127.in-addr.arpa  name = localhost.

             

            [root@proton ~]# ping proton.example.co

            PING proton.example.co (192.168.2.102) 56(84) bytes of data.

            64 bytes from proton.example.com (192.168.2.102): icmp_seq=1 ttl=64 time=0.032 ms

            64 bytes from proton.example.com (192.168.2.102): icmp_seq=2 ttl=64 time=0.040 ms

             

            Obviously "proton.example.co" is just additional label, alias (with last character truncated) to proton.example.com. Why and where the truncated domain name is coming from - is beyond me.

            • 19. Re: Host/domain name problem in /etc/hosts and /etc/resolv.conf
              Dude!

              If you want to find out the source of the problem I think it would be a good idea to use something like VirtualBox and perform a plain vanilla default OS installation. This usually takes only several minutes and may indicate that your ADSL modem, DNS server or local machine is the troublemaker.

              • 20. Re: Host/domain name problem in /etc/hosts and /etc/resolv.conf
                niksajur

                Oh no, thank you. I don't consider it being a problem. Just mentioned it for completeness and to satisfy my curiosity which is not worth wasting additional time. Even if it were a problem, I failed to see how vanilla default OS installation via VirtualBox could help anything to find out the source of it. I would be on my own, configuring the network from the ground up ... step by step ... and run into the same situation very soon. Anyway there is nothing wrong with "proton.example.co". I consider it being a "gift" that is equivalent to putting additional alias in /etc/hosts, for instance

                 

                192.168.2.102   proton.example.com proton proton.example.co

                 

                and that's all. The network is very stable, works fine and correctly, internet is very fast and never fails or disconnects. After all, there are two "decent verifiers" of the network correctness: Oracle database and grid infrastructure installations. If anything had been wrong with the network, the Net Configuration Assistant would have failed either in grid or database installation. And last but not least, there is the "uppermost verifier" of everything: OEM Cloud Control. It is one enormous web-java-perl based management system (6.3 GB unzipped installation software) whose installation lasts two times longer than grid and database installations both and is extremely sensible of network configuration deficiency. If anything in the network configuration had been at least ambiguous, it would have most definitely failed at retrieving the free ports for installation (see below) and refused to continue. That didn't happen and all install logs are perfectly clean.

                 

                [root@proton ~]# su - oracle -l -c 'cat ${OMS_HOME}/install/portlist.ini'
                Enterprise Manager Upload Http Port=4889
                Enterprise Manager Upload Http SSL Port=4903
                Enterprise Manager Central Console Http SSL Port=7802
                Node Manager Http SSL Port=7403
                Managed Server Http Port=7202
                Enterprise Manager Central Console Http Port=7788
                Oracle Management Agent Port=3872
                Admin Server Http SSL Port=7102
                Managed Server Http SSL Port=7301

                 

                where

                 

                OMS_HOME=${ORACLE_BASE}/product/oem/Middleware/oms
                ORACLE_BASE=/opt/app/oracle

                • 21. Re: Host/domain name problem in /etc/hosts and /etc/resolv.conf
                  Arpman

                  Have you considered the /etc/host.conf and /etc/sysconfig/network files?  You can learn about them in the man page for hostname.  The /etc/host is also relevant, but only if configured for it.  Read the man page for more information.

                  • 22. Re: Host/domain name problem in /etc/hosts and /etc/resolv.conf
                    niksajur

                    Arpman wrote:

                     

                    Have you considered the /etc/host.conf and /etc/sysconfig/network files?

                    Of course I have. The /etc/host.conf is resolver configuration file, similar to /etc/nsswitch.conf. Just like the later contains the entry 'hosts: files dns', the /etc/host.conf contains the entries 'order hosts,bind' and 'multi on'. Also, /etc/hosts and /etc/sysconfig/network are "in sync" with regard to host name 'proton.example.com'. Both HOSTNAME and DHCP_HOSTNAME are set to 'proton.example.com' in /etc/sysconfig/network and /etc/sysconfig/network-scripts/ifcfg-eth0. But all that has nothing to do with truncation. The question is: why does nslookup (and only nslookup, nothing else!) return the truncated domain name "example.co", instead of "example.com" which is in domain search list in /etc/resolv.conf? As I said, it's just matter of curiosity because it has no implications on network's functionality and can be safely ignored. Beside speedport.ip, it's just another DNS host. Both are active and pingable and without entries in /etc/hosts.

                    • 23. Re: Host/domain name problem in /etc/hosts and /etc/resolv.conf
                      niksajur

                      I have been constantly forgetting to mention something very important that additionally confirms and definitely proves that nothing is wrong with the network configuration, and that "weird" truncation is not weird at all, but very reasonable.

                       

                      When I turn off the ADSL modem/router box (no internet connection!), it doesn't affect the loopback adapter 127.0.0.1 localhost.localdomain nor proton.example.com on IP address 192.168.2.102. This is possible because eth0 interface is still capable of determining IP information for eth0 (inet addr: 192.168.2.102) and bringing up the eth0 interface, as long as LAN cable is attached to the router's LAN port. Thus both localhost.localdomain and proton.example.com are still active and pingable (by name or by IP address allowing me to start grid, database and OEM Cloud Control nicely), but not speedport.ip nor proton.example.co. Both speedport.ip and proton.example.co are DNS hosts and active only if internet connection is active and established. Therefore speedport.ip cannot be pinged by name nor by address 192.168.2.1. Also, proton.example.co cannot be pinged by name, although its address 192.168.2.102 can be pinged as it is eth0 inet address used locally by proton.example.com. The nslookup follows the same logic here. Being able to query only DNS nameservers and addresses, nslookup fails to query all three addresses: 127.0.0.1, 192.168.2.1 and 192.168.2.102 as it cannot find any DNS host on those addresses.

                       

                      This means that proton.example.co (DNS) and proton.example.com (known locally) are not conflicting at all, as they have nothing to do with each other, although they can share the same address. Being DNS hosts, the speedport.ip and proton.example.co are here just to recognize and activate ADSL router (192.168.2.1) and establish the internet connection on the second router's LAN port (192.168.2.102) respectively. The following outputs (with router turned off) confirm all what I said.

                       

                      [root@proton ~]# nslookup 192.168.2.1
                      ;; connection timed out; trying next origin
                      ;; connection timed out; trying next origin
                      ;; connection timed out; no servers could be reached

                       

                      [root@proton ~]# nslookup 192.168.2.102
                      ;; connection timed out; trying next origin
                      ;; connection timed out; trying next origin
                      ;; connection timed out; no servers could be reached

                       

                      [root@proton ~]# nslookup 127.0.0.1
                      ;; connection timed out; trying next origin
                      ;; connection timed out; trying next origin
                      ;; connection timed out; no servers could be reached

                       

                      Also

                       

                      [root@proton ~]# ipcalc --hostname 192.168.2.1
                      ipcalc: cannot find hostname for 192.168.2.1: Host name lookup failure

                       

                      [root@proton ~]# ping speedport.ip
                      ping: unknown host speedport.ip

                       

                      [root@proton ~]# ping 192.168.2.1
                      PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
                      From 192.168.2.102 icmp_seq=1 Destination Host Unreachable
                      From 192.168.2.102 icmp_seq=2 Destination Host Unreachable

                       

                      [root@proton ~]# ping proton.example.co
                      ping: unknown host proton.example.co

                       

                      but

                       

                      [root@proton ~]# ipcalc --hostname 192.168.2.102
                      HOSTNAME=proton.example.com

                       

                      [root@proton ~]# ping proton
                      PING proton.example.com (192.168.2.102) 56(84) bytes of data.
                      64 bytes from proton.example.com (192.168.2.102): icmp_seq=1 ttl=64 time=0.041 ms
                      64 bytes from proton.example.com (192.168.2.102): icmp_seq=2 ttl=64 time=0.052 ms

                       

                      [root@proton ~]# ping 192.168.2.102
                      PING 192.168.2.102 (192.168.2.102) 56(84) bytes of data.
                      64 bytes from 192.168.2.102: icmp_seq=1 ttl=64 time=0.034 ms
                      64 bytes from 192.168.2.102: icmp_seq=2 ttl=64 time=0.039 ms

                       

                      [root@proton ~]# ipcalc --hostname 127.0.0.1
                      HOSTNAME=localhost.localdomain

                       

                      [root@proton ~]# ping localhost
                      PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
                      64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.035 ms
                      64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.029 ms

                       

                      This can also explain the "weird" truncation. The suggested host/domain name in DHCP_HOSTNAME was obviously respected, but always truncating the last one or two characters in order to get the unique host name for DNS server, thus being able to distinguish and differentiate DNS hosts from local hosts, treating them separately as it can be clearly seen from the outputs above.

                      • 24. Re: Host/domain name problem in /etc/hosts and /etc/resolv.conf
                        Dude!

                        So it basically boils down to your ADSL modem or DNS or DHCP server providing wrong information.

                        • 25. Re: Host/domain name problem in /etc/hosts and /etc/resolv.conf
                          niksajur

                          > ... providing wrong information.

                           

                          But what's wrong here? What the information is wrong? Please tell me exactly what's wrong.

                           

                          I can set DHCP_HOSTNAME=boss.blablabla.com just to make the name different from HOSTNAME=proton.example.com, thus getting the DNS host name as it is, without being truncated. But what's the difference between the truncated "proton.example.co" and non-truncated "boss.blablabla.com"?

                           

                          BTW, neither DNS bind server (named) nor DHCP server (dhcpd) is running. The /usr/bin/nslookup belongs to bind-utils. The /sbin/dhclient and /sbin/dhclient-script belong to dhclient package. The nslookup works regardless of DNS server is running or not, and returns the same output with or without DNS server.

                          1 2 Previous Next