DNS lookup failing even though resolv.conf is correct

[avandemore]

This is how Linux utilizes DNS:

http://man7.org/linux/man-pages/man5/hosts.5.html
http://man7.org/linux/man-pages/man5/resolv.conf.5.html
http://man7.org/linux/man-pages/man5/ns ... onf.5.html

You can set your local domain, search order and whatever preferences you like there. Nagios can't fix your DNS resolving, that is on your DNS infrastructure. Nagios utilizes the same method nearly every other POSIX compliant system would. What needs to be done is Nagios needs to see the passive result exactly where trap host:service == nagios host:service.

This is most easily accomplish by setting the FQDN has the hostname and the host's IP in the address field, assuming you'll never re-IP the systems.

If you want to generate backend configurations for your unconfigured objects you can use this guide:

Monitoring Unconfigured Objects

[eloyd]

Again, "getting a result" could mean "I don't know the answer." The resolver only asks the second IP if the first IP times out. If the first IP simply doesn't know the answer, then that's the answer, and it never goes to the second IP listed in resolv.conf.

[snapon_admin]

Again, "getting a result" could mean "I don't know the answer." The resolver only asks the second IP if the first IP times out. If the first IP simply doesn't know the answer, then that's the answer, and it never goes to the second IP listed in resolv.conf.

Yeah that's exactly the issue we're running into I think. Doesn't seem like there's a great way to resolve that either, but that's just how it is. This topic can be closed up.

[snapon_admin]

I'm not sure what you're referring to here but from what I have observed the issue looks more like what Eric said. The windows DNS server was listed first, so when the trap was sent that's where it looked for the name resolution. When the response from that server was "I don't know" and not "I don't exist" it just took "I don't know" as the answer and didn't bother trying the second address. That's why, when I put the Unix DNS server first in that list it was able to resolve the name properly.

[avandemore]

Yeah that's exactly the issue we're running into I think.

If the NS resolver doesn't know the answer it will forward it up depending on the IP in question. Since yours is an internal IP, it with either forward to a higher level internal resolver or return empty. The empty result will end the inquiry as the DNS gave an answer. If your DNS is giving the wrong answer, fix the DNS.
Empty result:

Code: Select all

[root@avandemore-centos7 nagiosxi]# dig @8.8.8.8 192.168.0.1

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> @8.8.8.8 192.168.0.1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42580
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;192.168.0.1.                   IN      A

;; AUTHORITY SECTION:
.                       33257   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2016121301 1800 900 604800 86400

;; Query time: 32 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Dec 14 11:30:08 CST 2016
;; MSG SIZE  rcvd: 115

[eloyd]

Teach your Windows DNS server to forward to the Unix DNS server for things it doesn't know, and you'll be all set.

[snapon_admin]

Teach your Windows DNS server to forward to the Unix DNS server for things it doesn't know, and you'll be all set.

I do not manage the DNS servers so that's not really an option. I'm not sure how they are set up currently in respect to communication with each other.

[eloyd]

C'est le vie, I guess.

[tgriep]

Another option is to setup your own caching DNS server and use that one instead of the ones you do not have access to.
Take a look at this link for an example.
http://www.tecmint.com/install-caching- ... in-centos/