DNS resolution libc works, resolvers does not

Help!
1

Using version 2.6.18

I am updating a working haproxy configuration to be able to handle backend servers not being up yet at the time haproxy is starting. It’s a docker container running in kubernetes, so the resolve.conf file is kubernetes generated, if that’s relevant.

Following all the documentation, I’ve updated to use init-addr none and added a resolver with parse-resolve-conf and added healthchecks, however, I get 503’s.

I was under the impression libc and a resolver with parse-resolve-conf would both be using the local resolver, why might I be getting different results?

Here’s a sanitized version of the config I’m using:

global
  log                stdout       local0        warning
  maxconn            5000
  spread-checks      5

resolvers dns
 parse-resolv-conf
 accepted_payload_size 8192

defaults
  mode               http
  log                global
  option             forwardfor except 127.0.0.1/8
  option             abortonclose
  retries            1
  timeout            client 10m
  timeout            server 10m
  timeout            connect 4s
  timeout            http-keep-alive 20s
  default-server     check inter 30s slowstart 10s rise 1 fall 60 maxconn 500 weight 100 resolvers dns init-addr none

...(omitting front end config)

backend egbackend
 server egbackend egbackend-dev-<redacted>.<redacted>.svc:8081
2

Libc and the internal resolver are barely comparable, they behave differently in nearly every aspect.

The information provided is insufficient.

Copy and paste an actual servername you are trying to resolve and use the host command against the exact nameserver indicated in /etc/resolv.conf

Does it resolv correctly or does it fail?

Your internal hostnames are private, is there a search domain required to resolve it or is the FQDN really trailing with .svc.?

3

You’re right. I did need to update to the fqdn, it’s .svc.cluster.local

It does resolve from the nameserver in /etc/resolve.conf but updating in haproxy config didn’t solve the 503.

4

Realized I was running in deamon mode and was missing a lot of logs. It ended up being a healthcheck issue not dns :+1: