Hundreds of dns lookups per second for 8 digit hex address .addr.mydomain.consul

I take 10 seconds (just using my wristwatch) trace:

consul monitor -log-level trace > consul-trace.out

I get about 100-200k (depending on environment) dns requests.

Attempting to group them shows a mostly even distribution rate:

$ grep -oE 'name=\S+' consul-trace.out  | sort | uniq -c
   2623 name=0afe000b.addr.M.consul.
   2637 name=0afe000e.addr.M.consul.
   2636 name=0afe0031.addr.M.consul.
   2616 name=0afe0063.addr.M.consul.
   2627 name=0afe00c0.addr.M.consul.
   2621 name=0afe00d3.addr.M.consul.
   2623 name=0afe015a.addr.M.consul.
   2627 name=0afe015c.addr.M.consul.
   2650 name=0afe0195.addr.M.consul.
   2632 name=0afe0199.addr.M.consul.
   2651 name=0afe019c.addr.M.consul.

What is this?

Hi @jrwren,

Information about the .addr subdomain was recently added to Consul’s DNS documentation https://www.consul.io/docs/discovery/dns#srv-response-for-hosts-in-the-addr-subdomain. Hopefully that helps clarify what that domain is for.

As to why you’re seeing so many queries for those hosts, I’m not sure. Are the majority of your applications using SRV lookups to resolve upstream services?

Thanks. That makes sense.

No, most of my applications aren’t using SRV, but one big one is, haproxy. We are noticing a HUGE increase in the number of queries when moving from haproxy 1.9 to haproxy 2.4. I’m wondering if their resolvers behavior has changed.

JFYI to anyone else who happens to see this. haproxy fixed a bug.

Added to our haproxy.conf:
timeout resolve 30s

1 Like