I have different nameserver ip’s for different networks. Is it possible to just configure them all, and have haproxy figure out which ones exist, and ignore the ones that can’t be reached?
With this config haproxy does not start, when nameservers are not available.
resolvers dnssvrs1
nameserver dns1 192.168.10.xx:53
nameserver dns2 192.168.10.yy:53
nameserver dns3 aaa.aa.aaa.aaa:53
nameserver dns4 bbb.bb.bbb.bbb:53
I don’t know why haproxy would not start, just because some nameserver are unreachable. Maybe you can elaborate?
However, to answer your question: it’s a bad idea. Haproxy does not blacklist unreachable nameservers and stop querying them, there is not much heuristic involved here, when 3 out of 4 nameservers are unreachable you are probably gonna end up with a large amount of unnecessary DNS traffic.
The DNS resolver is extremely simplistic, it will not respect TTL and it also won’t back down from non-responding DNS servers.
More about the behavior in the docs at #5.3.2 :
https://cbonte.github.io/haproxy-dconv/2.0/configuration.html#5.3.2
I have a routing issue with a container, and aaa.aa.aaa.aaa:53 did not resolve, what will cause haproxy not to start at all. Only one dns server needs to fail for this to happen.
[ALERT] 220/115919 (3924259) : config : resolvers ‘dnssvrs1’: can’t connect socket for nameserver ‘aaa.aa.aaa.aaa’.
[ALERT] 220/115919 (3924259) : Fatal errors found in configuration.
This is on haproxy 2.2.
So aaa.aa.aaa.aaa
is a hostname, not an IP address?
not sorry it is an ip address that was not reachable because of routing.
Nameserver don’t need to be available (as in respond to DNS requests), but they need to be routable; if the connect() fails (like with a EHOSTUNREACH
- No route to host), then haproxy will refuse to start.
This is expected behavior, can be reproduced with blackhole routes:
route add -host IP-ADDRESS reject
(a ICMP host unreachable from a intermediate router likely leads to the same).
Hmmm, I do not get this design point. The reason I have multiple dns servers listed, is that if something is wrong with one, the others are still available.
Right, and when it’s not routable at all, something is seriously wrong with the setup, and you need to be aware.
But haproxy is a proxy, it is not a sysadmin tool. I would not implement it like this. It is not following standards and thus people are not expecting this behavior.
If I can run the proxy with 4 nameservers instead of 5, I would run it with 4 and not have it failed because of one.
apache, nginx etc all start whatever is in /etc/resolv.conf
Running is better than not running.
I don’t completely disagree with you, actually.
I suggest you file a feature request on github (even though your are not asking for a feature, it is a change request).
I would suggest we downgrade this to a warning instead of a critical alert. Make sure you include the information from this thread.