You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have an issue with IPV6 stack trying to resolve a lot AAAA records in Datacenters with IPV6 support.
On those datacenters, clients always try to use AAAA records now, and it is getting some important load on the DNS servers for those requests which are forwarded to some Consul Agents.
On those datacenters, most of the service queries are performed with AAAA request because ONLY looking for ipv6 records. In Consul minimum TTL value is hardcoded to 0, so DNS implementations cannot cache those negative values and keep repeating asking for AAAA records on the zone, while no record will be returned
We propose to add a new SOA settins to setup, so minimum ttl (which is used for negative TTL as described in https://tools.ietf.org/html/rfc2308 ) can be returned and DNS servers can cache this value and lower the load on Consul servers.
Settings and their default value (that would match the existing implementation) would be the following in DNS section of configuration:
We have an issue with IPV6 stack trying to resolve a lot AAAA records in Datacenters with IPV6 support.
On those datacenters, clients always try to use AAAA records now, and it is getting some important load on the DNS servers for those requests which are forwarded to some Consul Agents.
On those datacenters, most of the service queries are performed with AAAA request because ONLY looking for ipv6 records. In Consul
minimum TTL
value is hardcoded to 0, so DNS implementations cannot cache those negative values and keep repeating asking for AAAA records on the zone, while no record will be returnedWe propose to add a new SOA settins to setup, so
minimum ttl
(which is used for negative TTL as described in https://tools.ietf.org/html/rfc2308 ) can be returned and DNS servers can cache this value and lower the load on Consul servers.Settings and their default value (that would match the existing implementation) would be the following in DNS section of configuration:
Do you consider a PR to fix this if we provide it ?
Kind regards
The text was updated successfully, but these errors were encountered: