DNS resolve does not work HAProxy 2.1.2 Docker

Help!
1

I’m trying to use kubernetes resolver (coredns) to resolve the servers, but it doesn’t work. I did a tcpdump of the DNS queries that HAproxy sends:

20:25:00.164952 IP jira-nginx-764f99df4f-v7r24.56180 > kube-coredns.kube-system.svc.cluster.local.domain: 13876+ [1au] Type0 (Class 7168)? jira.staging.svc.cluster.local. (60)
20:25:00.165297 IP kube-coredns.kube-system.svc.cluster.local.domain > jira-nginx-764f99df4f-v7r24.56180: 13876 FormErr- 0/0/0 (48)
20:25:00.165340 IP jira-nginx-764f99df4f-v7r24.56180 > kube-coredns.kube-system.svc.cluster.local.domain: 13876+ [1au] Type0 (Class 256)? jira.staging.svc.cluster.local. (60)
20:25:00.165710 IP kube-coredns.kube-system.svc.cluster.local.domain > jira-nginx-764f99df4f-v7r24.56180: 13876 FormErr- 0/0/0 (48)

I’m not clear why it send invalid DNS queries, Wireshark says the DNS queries are malformed.

I have tested with dig, and it returns the correct results, it also works correctly with nginx.

Config:

global
  log stdout local0
  stats socket 127.0.0.1:9000 mode 660 level admin

frontend ft_web
  mode http
  bind 127.0.0.1:8080
  default_backend bk_web
  stats enable
  stats uri /ha
  stats refresh 5s

resolvers mydns
  parse-resolv-conf
  accepted_payload_size 512

backend bk_web
  mode http
  balance roundrobin
  cookie JSESSIONID prefix nocache
  server-template jira 5 jira.staging.svc.cluster.local.:8080 check resolvers mydns init-addr none resolve-prefer ipv4
2

You must not specify the trailing dot.

3

Works, thanks.

Can you explain why the trailing dot leads to an issue here?

4

Haproxy takes what the users configures and put’s it into a DNS query, where a trailing dot does not belong. When the trailing dot is in there as you can see from your tcpdump, kubernetes DNS responds with a FormErr.

edit: actually that is not completely correct. The reality is that the trailing dot confuses the DNS code in haproxy leading to a unparsable DNS packet. I have filed the following issue for clarification:

5

Thanks for raising the issue, the trailing dot is really common when you want to avoid to iterate through the search options in the resolv.conf usally.

6

Not with the haproxy resolver though, because it will really only send the hostname as is, which is why FQDN (without trailing dot) is required.

However this is not the first time this comes up and it’s also not properly documented, so let’s see if this can be improved.