EDNS Client Subnet: Powerful Signal Or Operational Trap?

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