May you preemptively whitelist LinkedIn.com NSes for EDNS-Client Subnet?
pub...@samir.ca
Samir Jafferali
Alex Dupuy
You wrote:
We currently have EDNS-CS enabled on 4 of our 8 NS and want to enable it on the remaining 4 this Wednesday. As we expect a traffic shift, we'd like to know how long the automatic whitelisting takes and what thresholds have to be met?Is there any way you may pre-whitelist our NSes before our change so that the traffic shift happens exactly during our change window?The zone we're changing is linkedin.com.
The recent RFC 7871 – EDNS Client Subnet (ECS) – provides extra IP address information to authoritative DNS name servers for Content Delivery Networks (CDNs) or other latency-sensitive services, to help them return accurate geo-located responses when responding to name lookups coming through public DNS resolvers. The RFC describes some features of ECS that authoritative name servers must implement; but implementors don’t always follow those requirements. There are also operational and deployment aspects of ECS that are not addressed in the RFC, but which can cause problems unless you are careful. If you are deploying ECS on your authoritative name servers and DNS zones, follow the guidelines below, or Google Public DNS may not send ECS data to your name servers, and may be unable to resolve names in your DNS zones.
Definitions of requirements
We use the following terminology for describing EDNS Client Subnet protocol operation in the guidelines in the next section, and note that if these requirements are not met, ECS is very likely to work poorly or not at all in some situations.
A name server implements (or supports) ECS if its response to a query with ECS option data is a reply with ECS option data (even if that reply has a global (/0) scope). If the reply does not have ECS option data that matches the query’s ECS subnet family, address, and source prefix length,1 the name server does not correctly implement ECS, and a recursive resolver that probes for ECS implementations may not detect it.
A zone is ECS-enabled if its name servers' responses to queries with ECS option data that has a non-zero prefix are replies with ECS option data that has non-zero scope.
Guidelines
All authoritative name servers for an ECS-enabled zone must implement ECS and enable it for the zone.
Even just one of many servers that does not implement ECS or enable it for the zone quickly becomes the source of most cached data. Its responses have global scope and are used (until their TTL expires) as the response for all queries for the same name (regardless of client subnet). Responses from servers that do implement ECS are only used
Authoritative name servers that implement ECS must do so for all zones being served from an IP address (or name server hostname) even if the zones are not ECS-enabled.
Intermediate resolvers that probe for ECS implementations may detect by IP address rather than name server hostname (let alone DNS zone) simply because the number of addresses is smaller than the number of name server hostnames and much smaller than the number of DNS zones. If an authoritative name server does not always send replies with ECS data in response to queries with ECS data (even for zones that are not ECS-enabled), a probing resolver may not send further queries with ECS data.
Authoritative name servers that implement ECS must answer all ECS queries with ECS, including negative and referral (delegation) responses.
Negative responses should use global scope (/0) for compatibility and caching.2
Authoritative name servers returning ECS-enabled CNAME responses SHOULD3 only include the first CNAME in the chain, and furthermore the final target of the CNAME chain should be ECS-enabled to the same granularity. Because of ambiguity in the ECS specification, some recursive resolvers (notably Unbound4) may return a response with the scope of the final non-CNAME domain (/0 if it is not ECS-enabled). The practical effect of this is usually limited, however, since Unbound is most often deployed as a local stub or forwarding resolver, and all of its clients would be likely to get the same response.
ECS data may contain IPv6 addresses even if your name servers are IPv4-only (and vice-versa, although IPv6-only name servers are rare).
You need to handle this correctly, with a valid ECS response (/0 scope is okay).
ECS for a zone can be enabled separately for IPv4 and IPv6 addresses.
When implementing ECS support on name servers that previously did not implement it, use new IP addresses (and name server hostnames) for ECS enabled zones.
Authoritative name servers that already implemented ECS but returned global scope results can start returning ECS enabled answers for a zone as soon as the TTLs for previous replies expire.
Intermediate resolvers that probe for ECS implementation very rarely try ECS queries for an IP address (or name server hostname) that they have learned does not implement ECS (repeatedly returning FORMERR, BADVERS, or simply failing to respond at all). New ECS implementations on those IP addresses (or name server hostnames) will be auto-detected very slowly, or not at all.
Make sure your network connections are reliable and that any response rate limiting is
Make sure your responses are timely (ideally within 1 second under reasonable load).
Using online Geo-IP lookup services to handle DNS ECS queries will not work reliably.