The host command resolves names put ping does not
In what universe does this makes any sense? The DNS server at 10.10.10.11 is good. I'm resolving names with it right now to post this question. I can do host
[root@www network-scripts]# date
Mon Feb 23 15:19:06 CST 2015
[root@www network-scripts]# host infradc2012.infrasupport.local
infradc2012.infrasupport.local has address 10.10.10.11
[root@www network-scripts]# ping infradc2012.infrasupport.local
ping: unknown host infradc2012.infrasupport.local
[root@www network-scripts]# date
Mon Feb 23 15:19:16 CST 2015
[root@www network-scripts]#
[root@www network-scripts]# more /etc/resolv.conf
Generated by NetworkManager
search bullseyebreach.com
nameserver 10.10.10.11
[root@www network-scripts]#
[root@www network-scripts]#
[root@www network-scripts]# more ifcfg-eth0
TYPE="Ethernet"
BOOTPROTO="static"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
NAME="eth0"
UUID="8df61ac9-355d-4d3c-8741-ca5c76d69b25"
ONBOOT="yes"
HWADDR="00:1A:4A:92:C6:01"
PEERDNS="yes"
PEERROUTES="yes"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"
BROADCAST="10.10.10.255"
IPADDR="10.10.10.7"
NETMASK="255.255.255.0"
NETWORK="10.10.10.0"
GATEWAY="10.10.10.1"
DNS1="10.10.10.11"
[root@www network-scripts]#
OK, the above didn't come from RHEL. It came from a Fedora 21 RHEV 3.5 virtual machine in a RHEV 3.5 environment I cloned. After cloning, I updated ifcfg-eth0 with its new MAC address and a new IP Address. What I don't get is why does ping resolve addresses differently than the host command?
thanks
- Greg Scott
Responses
- Does ifconfig show the eth0 device correctly up/configured?
- Is nscd enabled? (possible local caching)
- Can you use nslookup/dig directly to the DNS server from this host and resolve names? (possible local caching)
- What does nsswitch have configured for hosts?
Guru
6435 points
9 times out of 10, when nslookup/dig/hosts works but ping-by-name fails, it's because /etc/nsswitch.conf isn't set up properly. Usually, you'll want its hosts line to look like:
hosts: files dns
What they're probably thinking is that the "mdns4_minimal" will return valid hostnames. You could also try altering the line to look like
hosts: files mdns4_minimal [NOTFOUND=continue] dns myhostname
That way, it will still attempt to use MDNS to lookup hosts, but, if it doesn't find them via MDNS, it will continue on to look via DNS
Guru
6435 points
That would be expected. It's trying the MDNS service and waiting for it to time out. You'd get similar behavior if you had multiple DNS servers defined:
search your.domain.com
nameserver 192.168.28.53
nameserver 192.168.38.53
nameserver 192.168.58.53
If 192.168.28.53 was down, your resolution would have a 30s delay. If 192.168.28.53 and 192.168.38.53 were both down, you'd have a 60s delay.
If you know you'll never have MDNS set up on your network, better to simply nuke it and save yourself the couple seconds per lookup. If you want to some play around with MDNS, you'll either want to leave it there or remember to add it back so you're not stuck having to ask "why isn't ping finding thing via MDNS". ;)
Guru
6435 points
My initial response is "running Fedora's kind of like running OpenSolaris used to be: yeah, you get advanced access to features with the downside that not all the bugs may have been worked out when you're running 'upstream' code".
My guess would be, given the overall direction of Red Hat with respect to systemd and automatic system-configuration, the Fedora project is probably hoping to fully supplant manual system configuration. Such a path would also include networking (and name resolution) with auto-config tools. mDNS is one such component of 'zeroconf' system configuration utilities.
Guru
6435 points
Just to be clear, after installation of your VPN packages and updates, your /etc/nsswitch.conf file has two 'hosts:' lines?
In general, RPMs don't include logic to determine whether the OS is running on physical or virtual iron.
In general, RPMs that alter system configuration files should be better behaved than what your RPMs seem to be (assuming I'm reading your prior post, correctly). By "better behaved" I mean that they either don't crap up your config files (and causing nsswitch.conf to have more than one hosts: line counts as "crapping up"). Assuming the RPM-packagers did The Right Thing(TM), you might want to see if there's an /etc/nsswitch.conf.rpmsave (or similar) file sitting around. That file should contain the pre-update state of your /etc/nsswitch.conf file.
At any rate, you can typically sort out which, if any, yum actions resulted in a file's change. First thing to do is get the change time of your file. Once you have that, you can use usually use yum history to see which yum invocation most-closely corresponded to that timestamp. The output of yum history will include an ID number. You can then do yum history info <ID> to see which RPMs were installed as part of that yum action. Once you have your list of RPMs, you can see if any of them altered the file - either by directly replacing the file (use something like rpm -ql <RPMNAME> | grep filename) or executing a "preinstall", "postinstall" or similar script (rpm -q --scripts <RPMNAME>) .
Guru
6863 points
You have to enclose your pre-formatted text in 3 x tilde's
~~~
#!/bin/bash
echo "code here"
~~~
Red Hat
Guru
1310 points
Yes, this site uses the Markdown syntax. The ## signs are interpreted as various levels of Header formatting. At the bottom right of your text box you are typing in you will see a formatting help link to show you how to tweak it.
Like James says, use the ~~~ so surround your text as a code block.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.