Network troubles on Linux DHCP client

I have a slackware64 14.1 Linux host which acts as Samba4 DC/AD and is the domain DNS. I am using the Linux bind v. 9.9.5, not the bind built into Samba4. The Windows workstation DHCP clients work just fine.

I am having problems with a troublesome Slackware 14.1 client. I believe I have found the culprit, but first the problems:

1. `hostname -f` just returns the hostname, not the FDQN.

2. `host hplaptop` (a domain workstation) returns:
$ host hplaptop
Host hplaptop not found: 3(NXDOMAIN)

Open in new window

Config files are:

/etc/hosts:               localhost               viao.hprs.local


# Generated by dhcpcd from wlan0, eth1
# /etc/resolv.conf.head can replace this line
domain hprs.local
# /etc/resolv.conf.tail can replace this line

The culprit appears to be the 1st nameserver line in /etc/resolv.conf "nameserver". When I comment out this line in resolv.conf my problems go away.

The domain I care about is and the DC/AD DNS is, as shown. However, the viao host also has a wireless card and its DHCP assigned IP is (assigned from some wireless device in the building not associated with the hprs.local domain).

Therefore I conclude that the problem is that network resolution requests are going the to wireless nameserver which doesn't find the requested host(s). Even when I leave uncommented but move it *after* things still work.

So, long description but here are the questions:

I thought if DNS lookup failed with one nameserver it would try the next. Why doesn't it try when returns "Host hplaptop not found: 3(NXDOMAIN)"?

Can I do anything to a) get it to look at all name servers? If not b) get the nameserver listed 2nd? If not  c) not put into /etc/resolv.conf at all (that file is auto-generated by dhcpd)?
Who is Participating?
jmarkfoleyConnect With a Mentor Author Commented:
Actually, I figured out a solution. Yes, I need to know whether I am on the DC/AD or not. So, I created the script /etc/dhcpcd.exit-hook which gets run by dhcpcd:
# if the domain is found to be domain hprs.local, do not use wireless device name server

if [ -e /etc/resolv.conf ]
    x=`grep "^domain hprs.local" /etc/resolv.conf`

    if [ -n "$x" ]
        sed -e 's/^nameserver/#&/' -e 's/^#nameserver 192.168.0./nameserver 192.168.0./' \
            /etc/resolv.conf >/etc/

        mv /etc/ /etc/resolv.conf

Open in new window

This will run after the /etc/resolv.conf has been created by /lib/dhcpcd/dhcpcd-run-hooks. It checks to see if the domain is set to hprs.local. If so, it comments out all nameservers except for one(s) beginning with 192.168.0. So, it is semi-hard coded, but I don't see the hprs.local nameserver or at least the subnet ever changing. The nice part is that it is automatic. I don't have to physically turn off the wifi.

This works fine while connected to the Samba4 domain. I haven't tested it disconnected yet. Hopefully, it doesn't still find hprs.local as the domain when not connected. I don't think it will. Neither /etc/HOSTNAME nor /etc/hosts are referenced by any scripts in /lib/dhcpcd/dhcpcd-hooks/ and according to my understanding the domain name put into resolv.conf is obtained from the DHCP server.

I think this will do the trick!
(AD) you should never use/reference external name servers when using local non-public domains,

Allow your installed DNS server to perform the lookups, you could define external forwarders within the DNS server if you wish to offload external lookups to .....

The failover to the second DNS server only occurs on a timeout event I.e. No response from the DNS server to which a request was sent.
jmarkfoleyAuthor Commented:
(AD) you should never use/reference external name servers when using local non-public domains.

OK, but like I said, the /etc/resolv.conf file is created by dhcpc. So how to I prevent it from listing first, or even prevent it from putting into resolv.conf at all?
The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

In the scenario you have where you are testing something else while using a laptop getting a wifi feed with auto-allocating IP as well as auto-assigned DNS settings, one way is to

one option as suggested in the /etc/resolv.conf
you can add content to
that includes
domain hprs.local
search domain hprs.local

This will be prepended above the DHCPd set settings which may help in reducing the probability of this system ever hitting the assigned with the wifi IP.

Another option, is to adjust the /etc/rc.d/rc.inet1.conf such that it has a set DNS server
NAMESERVER="" might work in altering the resolv.conf. .....

Though you have to make sure once you are done with this test, to remove the NAMESERVER entry from the DHCPclient configuration of your wifi interface, or you will be unable to resolve
jmarkfoleyAuthor Commented:
Hmmm, sure I could "hard-code" as you suggest or even set the resolv.conf to read-only. But these techniques somewhat defeat one of the purposes of DHCP. This client host is a laptop and as such doesn't always stay connected to this LAN. If it goes a-travelling, I'd have to make sure to undo these hand-changes.

I thought I read somewhere there was a way to prevent a dhcp client from making changes to resolv.conf, no?
arnoldConnect With a Mentor Commented:
That is what I am unclear about, i.e. adding the nameserver= into the interface inet.inet1.conf
But that will result in the same issue, when you are off this LAN, the nameserver record in the wifi side will set to one that is not accessible.

The only remedy I see, is to when you are on the LAN (AD SAMBA/ADDC) disable the wifi. whether you have a physical switch or a Function key (Fn)+another keyboard key.
It could/should.
You might want to add -i to the grep just in case, the capitalization of any line items changes.
jmarkfoleyAuthor Commented:
I figured out something that works
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.