Add ECS option to EDNS responses where appropriate #4647
Conversation
If ECS opt is present in the request we will mirror it back and return a response with a scope of 0 (global) or with the same prefix length as the request (indicating its valid specifically for that subnet). We only mirror the prefix-length (non-global) for prepared queries as those could potentially use nearness checks that could be affected by the subnet. In the future we could get more sophisticated with determining the scope bits and allow for better caching of prepared queries that don’t rely on nearness checks. The other thing this does not do is implement the part of the ECS RFC related to originating ECS headers when acting as a intermediate DNS server (forwarding/recursive resolver). That would take a quite a bit more effort and in general it is expected that if users have sophisticated caching infrastructure that is ECS aware they probably aren’t using Consul to resolve non-consul related information.
agent/dns.go
Outdated
| @@ -135,6 +135,37 @@ func (d *DNSServer) ListenAndServe(network, addr string, notif func()) error { | |||
| return d.Server.ListenAndServe() | |||
| } | |||
|
|
|||
| func setEDNS(request *dns.Msg, response *dns.Msg, ecsGlobal bool) { | |||
There was a problem hiding this comment.
I would add a func comment here. I realize its not exported but even then I try to do it unless the implementation is trivial.
|
Just for clarification this implements the parts of RFC 7871. In particular we implement that parts of the RFC related to authoritative nameservers and partially those relating to forwarding resolvers (with regards to passing along ECS headers to the recursor). The only relevant bit for our use case we don't do is originate ECS headers for non-ECS requests when querying recursors on the behalf of other clients. This would enable "location" aware results from queried recursors that gets passed along to the clients. Like I mentioned above, if you have sophisticated caching infrastructure that is ECS aware then most likely you are not using Consul recursors and have the main recursor be an actual caching resolver that uses Consul as an upstream. This functionality isn't also mandatory. From my reading of the RFC this isn't strictly necessary, but could be a feature for better recursive resolving for non-ecs aware clients. |
If ECS opt is present in the request we will mirror it back and return a response with a scope of 0 (global) or with the same prefix length as the request (indicating its valid specifically for that subnet).
We only mirror the prefix-length (non-global) for prepared queries as those could potentially use nearness checks that could be affected by the subnet. In the future we could get more sophisticated with determining the scope bits and allow for better caching of prepared queries that don’t rely on nearness checks but that would require a larger change than we want to do right now.
The other thing this does not do is implement the part of the ECS RFC related to originating ECS headers when acting as a intermediate DNS server (forwarding/recursive resolver). That would take a quite a bit more effort and in general it is expected that if users have sophisticated caching infrastructure that is ECS aware they probably aren’t using Consul to resolve non-consul related information.