On Tue, April 5, 2016 4:22 pm, John Thurston wrote:
I have a couple of name servers which are not pingable. I have them in
my hosts.cfg as follows:
10.10.10.10 ns1-int.foo.com # noconn dns=ns1.foo.com
0.0.0.0 ns2-int.foo.com # noconn dns=ns2.foo.com
The first returns a green dns test result. The second returns a red
"Service dns on ns2-int.foo.com is not OK : Service unavailable." I
can't figure out why. I don't want to embed ip addresses in my
hosts.cfg, and I can't think why I should need to.
There is nothing telling when I run the test interactively with:
xymoncmd xymonnet --no-update --debug ns1-int.foo.com
nor for ns2-int.foo.com
When I snoop the interface while doing the above tests, the differences
are significant:
For ns1-int, I see xymon lookup ns1-int on the normal name server.
Then I also see it request ns1.foo.com from ns1-int.foo.com and get the
correct response. I'm not sure why the reverse lookup is there.
xymona -> d.foo.com DNS C ns1-int.foo.com. Internet Addr ?
d.foo.com -> xymona DNS R ns1-int.foo.com. Internet Addr
10.10.10.10
xymona -> ns1-int.foo.com DNS C ns1.foo.com. Internet Addr ?
ns1-int.foo.com -> xymona DNS R ns1.foo.com. Internet Addr
192.168.123.1
xymona -> d.foo.com DNS C 10.10.10.10.in-addr.arpa. Internet PTR ?
d.foo.com -> xymona DNS R 10.10.10.10.in-addr.arpa. Internet PTR
ns1-int.foo.com.
For ns2-int, however, the result is much simpler. I see xymon lookup
ns2-int on the normal name server. . . . and then nothing.
xymona -> d.foo.com DNS C ns2-int.foo.com. Internet Addr ?
d.foo.com -> xymona DNS R ns2-int.foo.com. Internet Addr
10.20.20.20
When I change the line in hosts.cfg for ns2-int from 0.0.0.0 to an ip
address, it works fine.
What is going on here? Why isn't the DNS test using the address it has
obviously retrieved from DNS?
It might be because DNS is tested distinct from the resolution involved in
initial xymonnet setup. In particular, pinging is done in parallel with
the TCP work, and IIRC there's a point where a lookup happens regardless
(although it's suppressed with testip indicated).
There's a latent bug in taking 0.0.0.0 as a not-invalid IP address which
might be part of this too... Even if it's not used, an IP other than that
(but without testip) might give you the behavior you'd wanted.
HTH,
-jc