/// article

EDNS Client Subnet: Powerful Signal Or Operational Trap?

By lordfrancs3

DNS steering depends on signals. The better the signal, the better the routing decision can be. One of the most useful signals in DNS steering is EDNS Client Subnet, usually called ECS. ECS can help an authoritative DNS system understand where the real user network may be located, even when the DNS query comes from a recursive resolver somewhere else. That sounds useful. And it is. But ECS also adds risk. It can affect caching. It can expose part of the client network. It may not be supported by every resolver. It may behave differently across DNS providers. It can make DNS steering more accurate in some cases, but harder to operate in others. That is why ECS should be treated carefully. It is a powerful signal, but it can also become an operational trap. The Problem ECS Tries To Solve Authoritative DNS usually sees the recursive resolver IP. It does not always see the real user IP. Simple flow: User device | | asks recursive resolver v Recursive resolver | | asks authoritative DNS v Authoritative DNS The authoritative DNS server usually receives the query from the recursive resolver. That means the source IP seen by authoritative DNS may be the resolver IP, not the real user IP. Example: Real user: Manila Recursive resolver: Singapore Authoritative DNS sees: Singapore resolver IP If the DNS steering system uses only the resolver IP, it may classify the requester as Singapore. That may lead to this answer: video.example.com. 60 IN A 198.51.100.20 Where: 198.51.100.20 = Singapore endpoint But the real user is in Manila. A Manila endpoint may be better. This is the problem ECS tries to solve. What ECS Does EDNS Client Subnet allows a recursive resolver to include part of the client network in the DNS query sent to authoritative DNS. Instead of saying: This query came from the resolver IP. ECS helps say: This query is for a client network like this. Example: Resolver IP: Singapore ECS client subnet: Philippine client network Authoritative DNS classification: Philippines Now the authoritative DNS server has a better signal. It can return the Manila endpoint: video.example.com. 60 IN A 203.0.113.10 Where: 203.0.113.10 = Manila endpoint ECS does not send the full user IP in the usual design. It sends a prefix. Example: 203.0.113.0/24 This means the authoritative DNS server sees the client network block, not necessarily the exact client address. ECS is defined in RFC 7871. Source: https://www.rfc-editor.org/rfc/rfc7871 ECS Uses EDNS0 ECS is an option under EDNS0. EDNS0 means Extension Mechanisms for DNS. Plain DNS has limits on what can be included in a DNS message. EDNS0 provides a way to extend DNS behavior by adding options. ECS is one of those options. EDNS0 is defined in RFC 6891. Source: https://www.rfc-editor.org/rfc/rfc6891 Why ECS Can Improve DNS Steering ECS can improve DNS steering when the resolver location is not a good sign of the user location. Example: Real user: Cebu Resolver IP: Hong Kong Without ECS: DNS steering may classify the requester as Hong Kong. With ECS: DNS steering may classify the requester as Philippines. This matters for services that use regional endpoints. Example endpoints: Manila endpoint: 203.0.113.10 Singapore endpoint: 198.51.100.20 Tokyo endpoint: 192.0.2.30 Without ECS: Resolver appears to be in Singapore. Answer: Singapore endpoint With ECS: Client subnet appears to be in the Philippines. Answer: Manila endpoint The same domain can receive a better answer because the requester classification improved. ECS Is A Hint, Not A Guarantee ECS should be treated as a hint. It is not perfect truth. A DNS steering system should not think: ECS exists, so the answer is always correct. A better mindset is: ECS exists, so the system has a better signal than resolver IP alone. ECS may help answer these questions: Which client network is behind this resolver? Which country should this query be classified under? Which ASN or prefix may represent the real requester? Which endpoint is likely better? But ECS does not prove real latency. It does not prove application quality. It does not prove the real user location with complete certainty. It only gives the authoritative DNS server more context. Why ECS Can Be Powerful ECS is powerful because it can correct a common DNS steering problem. The problem: Authoritative DNS sees the resolver, not the user. ECS helps by adding client network context. This can improve: Country-based steering ASN-aware steering Regional endpoint selection CDN endpoint choice Failover decisions Traffic reporting by client network Resolver misclassification handling Example: User: Mobile network in the Philippines Resolver: Public DNS resolver outside the Philippines Without ECS: The user may receive a foreign endpoint. With ECS: The user may receive a Philippine endpoint. For content delivery, streaming, software download, gaming, and regional APIs, this can matter a lot. Why ECS Can Become An Operational Trap ECS adds more information to DNS decisions. More information can improve accuracy. But more information can also create more states, more cache entries, more policy paths, and more troubleshooting work. Without ECS, the resolver may cache one answer for many users. With ECS, the resolver may need to cache different answers for different client subnets. Example without ECS: video.example.com Resolver cache: 1 answer for the resolver Example with ECS: video.example.com Resolver cache: Answer for 203.0.113.0/24 Answer for 198.51.100.0/24 Answer for 192.0.2.0/24 Answer for many other client prefixes This can increase cache variation. It can also increase query volume to authoritative DNS. This is one of the main operational concerns. Cache Fragmentation Cache fragmentation means the DNS cache gets split into many versions. Without ECS: One domain One record type One cached answer With ECS: One domain One record type Many client subnet versions Many cached answers This may reduce cache efficiency. A recursive resolver may need to ask authoritative DNS more often because the cached answer for one subnet may not apply to another subnet. This can increase: Authoritative DNS query volume Resolver cache memory use Policy decision count Log volume Monitoring complexity This does not mean ECS is bad. It means ECS has cost. A DNS steering system must know whether the benefit is worth the cost. Scope Prefix Matters ECS uses two important ideas: Source prefix length Scope prefix length The source prefix length tells how much of the client address is included in the query. Example: IPv4 client subnet: 203.0.113.0/24 The scope prefix length tells the resolver how broad the answer is intended to be cached for. Example: This answer is valid for this client subnet scope. This matters because the resolver needs to know when it can reuse a cached answer. If the scope is too narrow, caching becomes less efficient. If the scope is too broad, some users may receive a less accurate answer. This is one reason ECS requires careful design. Privacy Concerns ECS shares part of the client network with authoritative DNS. That improves routing context, but it also adds privacy risk. Even when ECS does not send the full user IP, it still reveals more client network information than a normal query from only the recursive resolver IP. This can matter because DNS queries may already expose sensitive behavior. Adding client network information increases metadata. RFC 7871 specifically discusses privacy concerns and recommends that the feature should not be enabled by default in all nameserver software. It also says operators should only enable it when there is a clear benefit for clients. Source: https://www.rfc-editor.org/rfc/rfc7871 A practical privacy rule: Use the shortest client prefix that still provides useful routing value. Do not request or forward more detail than needed. ECS Is Not Always Available A DNS steering system must work without ECS. Not all recursive resolvers send ECS. Some public DNS resolvers may send it only to selected authoritative systems. Some resolvers may reduce the subnet length. Some resolvers may remove it. Some resolver operators may disable it for privacy reasons. Some networks may use resolvers that do not support it. Because of this, ECS-based routing must never be the only path. A safe classification order may look like this: 1. If valid ECS exists, classify using ECS. 2. If ECS is missing, classify using resolver IP. 3. If resolver IP cannot be classified, use default policy. 4. If the preferred endpoint is unhealthy, use fallback. ECS should improve routing when available. It should not break routing when missing. ECS Can Produce Different Answers For The Same Resolver This is normal. A single recursive resolver may serve users from many locations. With ECS, the authoritative DNS server may return different answers based on the client subnet. Example: Same resolver IP: 198.51.100.50 Client subnet 1: Philippines Answer: Manila endpoint Client subnet 2: Singapore Answer: Singapore endpoint Client subnet 3: Japan Answer: Tokyo endpoint This is the point of ECS. But it also makes troubleshooting more detailed. An operator cannot only ask: What answer did this resolver receive? The better question is: What answer did this resolver receive for this client subnet? ECS And Logs If a DNS steering system supports ECS, logs should show whether ECS was used. Useful log fields: Requested name Record type Resolver IP ECS prefix, if present Classified country Classified ASN Matched policy Selected endpoint Fallback status Health state used Response TTL Snapshot or policy version These fields help answer: Did ECS change the answer? Was the resolver IP ignored? Was the ECS prefix valid? Which policy matched? Was fallback used? Without this detail, ECS-related routing problems become hard to debug. ECS And Observability Operators should measure ECS behavior. Useful metrics: Percentage of queries with ECS Percentage of queries without ECS Top resolvers sending ECS Top countries classified through ECS Answer distribution with ECS Answer distribution without ECS Fallback rate with ECS Fallback rate without ECS Unknown ECS prefix rate Invalid ECS option count Cache variation by subnet Query volume increase after enabling ECS These metrics show whether ECS helps or hurts. Example questions: Are users receiving better regional answers? Did authoritative query volume increase too much? Are some resolvers sending unexpected ECS values? Are many ECS-based answers falling back? Are policies too specific? ECS should be measured before it is trusted. ECS And Policy Design ECS can make policy more specific. Example: If ECS country is PH, return Manila. If ECS country is SG, return Singapore. If ECS is missing, use resolver country. But too many specific rules can become hard to operate. Bad policy design: One rule for every small client subnet. Thousands of manual exceptions. No clear default. No fallback path. No health override. Better policy design: Use broad regional rules. Use ASN-specific rules only when measured. Use prefix-specific rules only for known exceptions. Always define default answers. Always check health before returning an answer. ECS should help classification. It should not turn the routing policy into a large collection of fragile exceptions. ECS And Health Checks ECS helps decide which endpoint is preferred. Health checks decide whether that endpoint is usable. Example: ECS classification: Philippines Preferred endpoint: Manila Manila health: Unhealthy Fallback: Singapore Answer: video.example.com. 60 IN A 198.51.100.20 ECS should not override health. A nearby unhealthy endpoint is still a bad endpoint. A safe rule: ECS may choose the preferred path. Health decides if that path can be returned. ECS And TTL TTL still matters when ECS is used. Example: video.example.com. 60 IN A 203.0.113.10 A TTL of 60 seconds means the resolver may cache the answer for 60 seconds. But with ECS, the cache may be tied to the client subnet scope. This can create many cached answers. Lower TTL can make policy changes take effect faster, but it can increase query volume. Higher TTL can reduce query volume, but it can delay steering changes. A practical rule: Choose TTL based on failover needs, query volume, and cache behavior. ECS does not remove TTL trade-offs. It adds another layer to them. ECS And Anycast Resolvers Many public DNS resolvers use anycast. Anycast allows the same IP address to be announced from many locations. That means the resolver IP may not clearly identify one physical location. A query from a public resolver may arrive from a node near the user, or from another node depending on routing. ECS can help by adding client subnet information. But anycast behavior can also make troubleshooting harder. Operators may need to know: Which resolver IP sent the query? Was ECS included? Which client subnet was included? Which authoritative DNS site received the query? Which answer was returned? ECS helps, but it does not remove the need for good logs. ECS And Public DNS Resolvers Public DNS resolvers may handle ECS differently. Some may send ECS. Some may not. Some may send it only to selected authoritative DNS systems. Some may reduce the prefix to protect user privacy. Because of this, a DNS steering system should not assume universal ECS behavior. A safe design treats public resolver traffic like this: Use ECS when present. Use resolver IP when ECS is missing. Avoid over-specific assumptions. Measure answer quality. Keep fallback rules ready. ECS And Resolver Whitelisting Some operators choose to use ECS only with known resolvers. This can reduce risk. Example: Accept ECS from known resolver groups. Ignore ECS from unknown or untrusted sources. Use resolver IP fallback when ECS is ignored. This can help avoid bad or unexpected ECS behavior. But it also adds management work. The resolver list must be maintained. If the list becomes stale, good ECS signals may be ignored or bad signals may be accepted. ECS And Security ECS also raises security concerns. A system must validate ECS input. Bad inputs should not crash the DNS server, bypass policy, or create unstable answers. Practical checks: Validate address family. Validate prefix length. Reject malformed ECS options. Limit accepted prefix detail. Avoid trusting ECS from unexpected sources. Rate-limit abusive query patterns. Log invalid ECS behavior. Security is not only about attacks. It is also about keeping the DNS answering path stable under unusual input. When ECS Is Worth Using ECS may be worth using when: Resolvers are often far from users. Services have multiple regional endpoints. Wrong regional answers cause real performance problems. Operators can measure the result. The DNS system can handle cache variation. The privacy trade-off is acceptable. Fallback behavior is clear. Example use cases: CDN endpoint selection Video streaming Software downloads Regional APIs Game patch delivery Large public web services Network-aware traffic steering ECS is most useful when location-sensitive answers matter. When ECS May Not Be Worth It ECS may not be worth using when: The service has only one endpoint. Regional choice does not matter. The traffic volume is small. The privacy trade-off is not acceptable. The system cannot observe ECS behavior. The authoritative DNS platform cannot handle more cache variation. The policy team cannot maintain more specific rules. If ECS does not clearly improve the user experience, it may only add risk. A simple DNS steering system without ECS may be better for many services. Common ECS Mistakes Mistake 1: Assuming ECS Is Always Present Some resolvers do not send ECS. The system must still work well without it. Mistake 2: Trusting ECS Too Much ECS is useful, but it is still only a signal. It should be validated and measured. Mistake 3: Ignoring Cache Growth ECS can create more cache variations. This can increase query volume and memory use. Mistake 4: Using Too Specific Prefixes More detail is not always better. Use only the prefix length needed for useful routing. Mistake 5: No Privacy Review ECS adds client network metadata. That should be reviewed before deployment. Mistake 6: No Observability If operators cannot tell when ECS changed an answer, troubleshooting becomes difficult. Mistake 7: No Fallback Policy ECS must be optional. Missing ECS should not cause poor or broken answers. Practical ECS Decision Flow A practical ECS-aware DNS steering flow may look like this: Receive DNS query | Check requested name and record type | Check if valid ECS exists | If ECS exists, classify by ECS prefix | If ECS is missing, classify by resolver IP | Map classification to country, ASN, or prefix policy | Check endpoint health | Apply fallback if needed | Return DNS answer with TTL | Log whether ECS was used This flow keeps ECS useful without making it mandatory. Practical Rule For Operators Use this rule: ECS should improve decisions, not become a dependency. A DNS steering system should work with ECS. It should also work without ECS. That is the safest design. How This Fits The Article Series The earlier articles explained these ideas: Article 1: Authoritative DNS can influence traffic direction. Article 2: The control plane prepares decisions, while the data plane answers queries. Article 3: DNS steering is not the same as load balancing. Article 4: Geography, latency, and network distance are related, but not the same. Article 5: Requester classification uses IP, ASN, country, resolver signals, and context. This article focuses on one special requester signal: EDNS Client Subnet ECS can improve requester classification when the resolver IP is not enough. But it also brings caching, privacy, operational, and troubleshooting concerns. Key Takeaways EDNS Client Subnet allows a resolver to include part of the client network in a DNS query. ECS can help authoritative DNS make better routing decisions when the resolver is far from the real user. ECS is useful for regional routing, CDN selection, streaming, downloads, and other location-sensitive services. ECS is not always available. ECS can increase cache variation and query volume. ECS adds privacy concerns because it shares client network metadata. ECS should be validated, measured, logged, and treated as optional. A good DNS steering system uses ECS when it helps, falls back safely when it is missing, and avoids depending on it as the only signal. The main question is not: Should every DNS steering system use ECS? The better question is: Does ECS improve routing enough to justify the operational and privacy cost? In the next article, we will discuss Designing Fallback Logic For Reliable DNS Steering. Sources RFC 7871, Client Subnet in DNS Queries: https://www.rfc-editor.org/rfc/rfc7871 RFC 6891, Extension Mechanisms for DNS: https://www.rfc-editor.org/rfc/rfc6891 RFC 1034, Domain Names, Concepts and Facilities: https://www.rfc-editor.org/rfc/rfc1034 RFC 1035, Domain Names, Implementation and Specification: https://www.rfc-editor.org/rfc/rfc1035