2

I am trying to find out why multiple search domains do not work with Debian 8.8.0. If you add the search domains in /etc/resolv.conf it will only work with one of them & in this case domain1.local works but domain2.local will not.

If you manually append the FQDN it works fine. This is for any and all CLI based tools: nslookup, ping, iperf, nmap, curl, wget ect. I have seen this before where Debian does not work with .local domains - and you have to remove avahi which I have already done to get the first .local domain working: domain1.local.

I have had multiple .local & other domain's working but with this version of Debian 8.8.x it is not working.

user@host:~$ uname -a
Linux host 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 (2017-06-26)     x86_64 GNU/Linux


user@host:~$ cat /etc/resolv.conf

nameserver 192.16.1.110
### Standard Search domains:
search domain1.local domain2.local domain3.local domain4.local

search domain - domain1 automatically appends the domain1.local and works for nslookup, ping ect.

user@host:~$ ping host1
PING host1.domain1.local (192.16.1.110) 56(84) bytes of data.
64 bytes from host1.domain1.local (192.16.1.110): icmp_seq=1 ttl=118    time=63.6 ms

user@host:~$ nslookup host1
Server:     192.16.1.110
Address:    192.16.1.110#53

Name:   host1.domain1.local
Address: 192.16.1.110

domain2 will not automatically be appended to the host (hosty) in this example. It will not find hosty with an nslookup from the dns server in /etc/resolv.fon (although it does exist). However - if you append the FQDN and run an nslookup, ping, curl,nmap,wget or any other cli based ip communication it works.

user@host:~$ nslookup hosty
;; Got SERVFAIL reply from 192.16.1.110, trying next server
;; Got SERVFAIL reply from 192.16.1.111, trying next server
Server:     192.16.1.110
Address:    192.16.1.110#53

** server can't find hosty: SERVFAIL

user@host:~$ ping hosty
ping: unknown host hosty

If we append domain2.local on the end of the host it can ping, nslookup, or other.

ping,nslookup & curl working with fqdn

user@host:~$ ping hosty.domain2.local
PING hosty.domain2.local (192.16.48.20) 56(84) bytes of data.
64 bytes from hosty.domain2.local (192.16.48.20): icmp_seq=1 ttl=119 time=63.6 ms

nslookup with fqdn:

user@host:~$ nslookup hosty.domain2.local
Server:     192.16.1.110
Address:    192.16.1.110#53

Name:   hosty.domain2.local
Address: 192.16.48.20

user@host:~$ curl hosty.domain2.local
curl: (7) Failed to connect to hosty.domain2.local port 80: Connection refused

It is worth mentioning that I have this identical configuration on a Ubuntu 16.04 workstation working with around 7 search domains.

The new Debian 8.8.x servers have the issue with working with more than 1 search domain. I must be missing some simple additional configuration that is required for Debian that is slightly different than Ubuntu.

  • Try using nslookup -debug to see the exact queries that are being tried. The key to the problem may be that you're getting SERVFAIL errors rather than NXDOMAIN. Also, dig is generally a better debugging tool than nslookup. – Barmar Aug 4 '17 at 23:59
  • I did use dig and it does the same thing. If I dig with the FQDN it works. If I debug it is trying to append the domain1.local to the host so that is why it is returning with the serverfail. – Alex Tomko Aug 5 '17 at 0:08
  • 1
    You also need to use the +search option to dig to make it append search domains. – Barmar Aug 5 '17 at 0:11
  • 1
    Of course it's trying to append domain1.local. It tries each domain in order: first it appends domain1.local, if that can't be found it appends domain2.local, and so on until it gets success. The server should return an NXDOMAIN response for hosty.domain1.local, then it will try the next domain. – Barmar Aug 5 '17 at 0:12
0

From resolvconf manual, concerning dns-search

The dns-nameservers option is also accepted and, unlike dns-nameserver, can be given multiple arguments, separated by spaces. The dns-domain option is deprecated in favor of dns-search.

The resulting stanza might look like the following example.

iface eth0 inet static
    address 192.168.1.3
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameserver 192.168.1.254
    dns-nameserver 8.8.8.8
    dns-search foo.org bar.com

N.B.: On a machine where resolvconf has just been or is about to be installed and which previously relied on a static /etc/resolv.conf file,

• the nameserver information in that static file, (which is to say the information on nameserver, domain, search and sortlist lines) should be migrated to the appropriate iface stanza(s) in /etc/network/interfaces(5) as just described.

disclaimer: I usually delete network manager, resolvconf and systemd from my Debian servers.

  • I attempted this configuration however I like to rely on the /etc/resolv.conf for DNS. It does not work either with dns-nameserver in the ethx's inside of /etc/network/interfaces either. This server has anywhere from 10-15 interfaces doing alot of routing for automation ect for internal networks. The servers do not rely on resolvconf and must be staticly managed. – Alex Tomko Aug 4 '17 at 18:54
  • 1
    I also always remove resolvconf, avahi, network-manager from any servers. – Alex Tomko Aug 4 '17 at 18:56
  • # eth4 iface eth4 inet static address 172.19.51.252 netmask 255.255.255.0 dns-nameservers 192.16.48.20 dns-search domain2.local # eg - same failed results. – Alex Tomko Aug 4 '17 at 19:02
0

Ok - so this was pretty oversighted of me but here was the issue. I had the domain1.local listed under the domain parameter in the /etc/resolv.conf

### Standard Search domains:
search domain1.local domain2.local
domain domain1.local # removed this line

After I ran the debug on nslookup and noticed that it was trying to append domain1.local for the nslookup I removed this and clearly it fixed the issue.

user@host:~$ nslookup hosty
Server:     192.16.1.110
Address:    192.16.1.110#53

Name:   hosty.domain2.local
Address: 192.16.48.20

Pretty stupid of me but just in case someone else makes the same mistake maybe this could help them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.