Inside Requester Classification: IP, ASN, Country, And Resolver Signals

DNS steering depends on one basic question:

Who is asking?

The answer is not always simple.

When an authoritative DNS server receives a query, it usually does not see the real user directly. It often sees the recursive resolver. That resolver may represent one person, one office, one ISP, one mobile network, one public DNS provider, or many users at the same time.

Because of this, DNS steering needs requester classification.

Requester classification is the process of reading available DNS query signals and turning them into useful routing information.

A DNS steering system may classify a query by:

Source IP
Resolver IP
Country
Region
ASN
Network prefix
EDNS Client Subnet
Requested name
Record type
Health and policy context

Classification is not perfect.

It is a best effort decision based on the signals available at query time.

The goal is not to know everything.

The goal is to make a safe and useful routing decision.

Why Requester Classification Matters

DNS steering needs classification because the same domain may need different answers for different requesters.

Example:

video.example.com

A user from the Philippines may receive a Manila endpoint.

A user from Singapore may receive a Singapore endpoint.

A user from Japan may receive a Tokyo endpoint.

A user from a specific ISP may receive a different endpoint because that ISP has a better path to one location.

A user whose preferred endpoint is unhealthy may receive a fallback endpoint.

Without requester classification, the DNS system has fewer choices.

It may return the same answer to everyone.

That may work for simple services, but it becomes weak when the service runs across many regions, networks, or edge locations.

The First Signal: Source IP

The source IP is the IP address seen by the authoritative DNS server.

In many DNS queries, this source IP belongs to the recursive resolver.

Example:

Real user:
Phone in Manila

Recursive resolver:
ISP resolver in Manila

Authoritative DNS sees:
ISP resolver IP in Manila

In this case, resolver IP may be a useful signal.

But this is not always true.

Example:

Real user:
Laptop in Manila

Recursive resolver:
Public resolver in Singapore

Authoritative DNS sees:
Public resolver IP in Singapore

In this case, the authoritative DNS server may think the requester is in Singapore.

That may lead to a Singapore answer, even if the real user is in Manila.

This is why source IP must be interpreted carefully.

DNS standards describe the DNS query and response process, but they do not make the authoritative server automatically know the real user behind a recursive resolver.

Sources:

https://www.rfc-editor.org/rfc/rfc1034
https://www.rfc-editor.org/rfc/rfc1035

Resolver IP Versus Real User IP

This is one of the most important concepts in DNS steering.

The resolver IP is not always the user IP.

A recursive resolver works on behalf of the user.

That means the authoritative DNS server often receives a query from the resolver, not from the user device.

Simple flow:

User device
    |
    | asks recursive resolver
    v
Recursive resolver
    |
    | asks authoritative DNS
    v
Authoritative DNS

The authoritative DNS server may only see the recursive resolver.

This matters because the resolver location and the real user location may be different.

Example:

User location:
Davao

Resolver location:
Manila

Authoritative DNS classification:
Manila

This may still be acceptable if Manila is a good endpoint.

But another example may be worse:

User location:
Cebu

Resolver location:
Hong Kong

Authoritative DNS classification:
Hong Kong

If the system blindly trusts resolver location, it may return a Hong Kong endpoint instead of a Philippine endpoint.

The Second Signal: Country

Country is one of the most common DNS steering signals.

A system may map the requester IP to a country.

Example:

Requester IP:
203.0.113.50

Estimated country:
Philippines

Then the system may apply a country policy:

If country is PH, return Manila endpoint.
If country is SG, return Singapore endpoint.
If country is JP, return Tokyo endpoint.

Country-based routing is simple and useful.

It can help avoid clearly poor decisions.

Example:

A Philippine requester should usually not be sent to a European endpoint if a healthy Asian endpoint exists.

But country data is still an estimate.

IP geolocation providers also warn that IP geolocation is not always exact. Country-level data is usually more reliable than city-level data, while VPNs, proxies, mobile networks, and ISP routing practices can reduce accuracy.

Sources:

https://support.maxmind.com/knowledge-base/articles/maxmind-geolocation-accuracy
https://support.maxmind.com/knowledge-base/articles/restrictions-on-ip-geolocation

The Third Signal: Region Or City

Some systems classify requesters by region or city.

Example:

Country:
Philippines

Region:
Metro Manila

City:
Quezon City

This can be useful when a service has many local endpoints.

But city-level classification can be risky.

IP addresses do not always map cleanly to a city.

A mobile user may appear in a different city.

A corporate network may exit from a central office.

A public resolver may be located far from the actual user.

A VPN may hide the user location completely.

Because of this, city-level DNS steering should be used with care.

A practical rule is:

Use country as a broad signal.
Use region or city only when you have enough proof that it improves routing.

The Fourth Signal: ASN

ASN means Autonomous System Number.

An autonomous system is a network or group of networks under one routing policy.

An ASN may belong to:

An ISP
A mobile network
A cloud provider
A large company
A university
A content network

ASN matters because network performance often depends on the network operator.

Two users in the same country may need different answers.

Example:

PH ISP A:
Best path is Manila.

PH ISP B:
Best path is Singapore.

PH ISP C:
Best path is Manila.

A country-only policy would treat all three as the same.

An ASN-aware policy can handle them differently.

Example:

If country is PH and ASN is ISP A, return Manila.
If country is PH and ASN is ISP B, return Singapore.
If country is PH and ASN is unknown, return Manila.

ASN is especially useful when operators have real measurements showing that one network performs better through a specific endpoint.

IANA maintains the Autonomous System Number registry.

Source:

https://www.iana.org/assignments/as-numbers/as-numbers.xhtml

ASN Is Useful, But Not Perfect

ASN improves requester classification, but it does not solve every problem.

An ASN may cover a large network.

A large ISP may serve many cities, provinces, or islands.

A cloud provider ASN may represent many customers.

A corporate network may route traffic through another country.

A public DNS provider may use anycast.

Because of this, ASN should not be used alone.

Better classification may combine:

Country
ASN
Resolver IP
Network prefix
Health state
Observed performance
Fallback rules

Example:

Country: PH
ASN: ISP B
Resolver IP: known resolver group
Preferred endpoint: Singapore
Fallback endpoint: Manila

This is more useful than only checking the country.

The Fifth Signal: Network Prefix

A network prefix is a block of IP addresses.

Example:

203.0.113.0/24
198.51.100.0/24
192.0.2.0/24

A DNS steering system may classify a requester by matching the source IP or ECS value against known network prefixes.

This is useful when a policy must be more specific than ASN.

Example:

Most users from ISP A should use Manila.
But users from one ISP A prefix should use Singapore.

Policy:

If requester prefix is 203.0.113.0/24, return Singapore.
If requester ASN is ISP A, return Manila.

Prefix-based classification can be powerful, but it needs careful management.

Too many prefixes can make policy harder to maintain.

Old or incorrect prefix data can cause wrong answers.

A safe system should validate prefix rules and provide defaults when no prefix matches.

The Sixth Signal: EDNS Client Subnet

EDNS Client Subnet, or ECS, allows a recursive resolver to send part of the client network to authoritative DNS.

This helps when the resolver IP is far from the real user.

Example:

Resolver IP:
Singapore

ECS value:
Client network in the Philippines

Better classification:
Philippines

Without ECS, the system may classify the requester as Singapore.

With ECS, the system may classify the requester as Philippines.

This can improve geographic routing.

But ECS has trade-offs.

It can affect DNS caching because different client subnets may receive different answers.

It can also raise privacy concerns because it shares part of the client network with authoritative DNS.

ECS is defined in RFC 7871.

Source:

https://www.rfc-editor.org/rfc/rfc7871

ECS Should Not Be Blindly Trusted

ECS is useful, but it should not be treated as perfect.

Important limits:

Not all resolvers send ECS.
Some resolvers remove ECS.
Some resolvers reduce subnet detail.
Some resolvers may send broad prefixes.
Some systems may prefer privacy over accuracy.
ECS can increase cache variation.

A practical DNS steering system should support ECS when present, but still work safely when ECS is missing.

Example logic:

If ECS is present and valid, classify using ECS.
If ECS is missing, classify using resolver IP.
If both are unknown, use default policy.

The Seventh Signal: Requested Name

The requested DNS name is also a classification signal.

Example:

www.example.com
api.example.com
video.example.com
download.example.com

Different names may need different steering policies.

Example:

www.example.com:
Use regional web endpoints.

api.example.com:
Use stable API regions.

video.example.com:
Use edge delivery endpoints.

download.example.com:
Use high-capacity download endpoints.

The requester may be the same, but the requested service may change the best answer.

This means requester classification should not be separated from service context.

A Philippine requester may receive Manila for one hostname and Singapore for another hostname if the services have different design requirements.

The Eighth Signal: Record Type

The DNS record type also matters.

Common query types include:

A
AAAA
CNAME
MX
TXT
NS

For DNS steering, A and AAAA records are often the main focus.

A returns IPv4 addresses.

AAAA returns IPv6 addresses.

Example:

app.example.com. 60 IN A 203.0.113.10
app.example.com. 60 IN AAAA 2001:db8::10

A DNS steering system may have different policy for IPv4 and IPv6.

Example:

IPv4 users in PH use Manila.
IPv6 users in PH use Singapore until Manila IPv6 is ready.

This is another reason classification should include the record type.

The Ninth Signal: Transport And Resolver Behavior

Some DNS systems also observe query transport and resolver behavior.

Examples:

UDP query
TCP query
DNS over TLS resolver
DNS over HTTPS resolver
Anycast public resolver
Known ISP resolver
Enterprise resolver

The authoritative DNS server may not always know all of these details directly, but operators can still classify known resolver groups.

Example:

Known ISP resolver group:
Use country and ASN policy.

Known public resolver group:
Prefer ECS when present.

Unknown resolver:
Use safe default policy.

Resolver behavior matters because not all resolvers handle caching, ECS, and query forwarding in the same way.

Building A Classification Order

A DNS steering system should define a clear order for classification.

Example:

1. Check requested name and record type.
2. Check whether valid ECS exists.
3. If ECS exists, classify using ECS prefix.
4. If ECS is missing, classify using resolver IP.
5. Map IP to country and ASN.
6. Match specific prefix policy.
7. Match ASN policy.
8. Match country policy.
9. Check endpoint health.
10. Use fallback or default answer.

This order should be clear and predictable.

Operators should be able to answer:

Why did this requester receive this DNS answer?

If the system cannot explain the answer, troubleshooting becomes difficult.

Example: Simple Country Classification

Assume this policy:

PH requesters use Manila.
SG requesters use Singapore.
JP requesters use Tokyo.
Unknown requesters use global endpoint.

Query:

Requested name:
video.example.com

Resolver IP:
203.0.113.50

Estimated country:
PH

Answer:
Manila endpoint

This is simple and easy to understand.

But it may fail if the resolver location does not match the real user location.

Example: Resolver IP Misclassification

Assume this query:

Real user:
Manila

Resolver IP:
Singapore

ECS:
Missing

Classification:

Country:
SG

Answer:
Singapore endpoint

This may still work if Singapore performs well.

But if Manila is better, the answer is not ideal.

This is a common DNS steering problem.

The system used the best signal it had, but the signal did not fully represent the real user.

Example: ECS Improves Classification

Now assume ECS is present:

Real user:
Manila

Resolver IP:
Singapore

ECS:
Philippine client prefix

Classification:

Country:
PH

Answer:
Manila endpoint

In this case, ECS helped the authoritative DNS system make a better decision.

But the system must still handle the case where ECS is missing.

Example: ASN Changes The Answer

Assume these measurements:

PH ISP A to Manila:
Fast

PH ISP B to Manila:
Slow

PH ISP B to Singapore:
Fast

Policy:

If country is PH and ASN is ISP A, return Manila.
If country is PH and ASN is ISP B, return Singapore.
If country is PH and ASN is unknown, return Manila.

Query:

Country:
PH

ASN:
ISP B

Answer:
Singapore endpoint

This is not a geography-only decision.

It is a network-aware decision.

Example: Health Overrides Classification

Assume this query:

Country:
PH

ASN:
ISP A

Preferred endpoint:
Manila

Manila health:
Unhealthy

Fallback:
Singapore

Answer:

Singapore endpoint

Even if classification says Manila is preferred, health should prevent returning a known bad endpoint.

This is a key safety rule:

Classification chooses the preferred path.
Health decides whether that path is usable.

Example: Missing Signals

Sometimes classification cannot produce a strong answer.

Example:

ECS:
Missing

Resolver IP:
Unknown

Country:
Unknown

ASN:
Unknown

The system should not fail just because signals are missing.

It should use a safe default.

Example:

Return global endpoint.

Or:

Return last known safe default pool.

Missing data should be expected.

A good DNS steering system treats missing signals as normal, not as an unusual event.

Common Classification Mistakes

Mistake 1: Treating Resolver IP As The Real User

Resolver IP is useful, but it may not be the real user.

This mistake can send users to the wrong region.

Mistake 2: Trusting City-Level Location Too Much

City-level IP geolocation can be inaccurate.

Use it only when you have proof that it improves decisions.

Mistake 3: Ignoring ASN

Country alone can be too broad.

ASN can show network differences inside the same country.

Mistake 4: Depending Too Much On ECS

ECS is helpful when present, but not universal.

The system must work without it.

Mistake 5: Ignoring Health

A perfect classification is useless if it returns an unhealthy endpoint.

Health must protect the final answer.

Mistake 6: No Default Policy

Every policy needs a default.

Without a default, unknown requesters may get poor answers or no useful answer.

What Operators Should Measure

Requester classification should be measured.

Useful metrics include:

Queries by country
Queries by ASN
Queries by resolver IP
Queries with ECS
Queries without ECS
Policy match rate
Default policy usage
Fallback usage
Endpoint answer distribution
Unknown country rate
Unknown ASN rate
Health override count

These metrics help operators find classification problems.

Example questions:

Why are many Philippine users classified as Singapore?
Which resolvers send ECS?
Which ASNs use fallback often?
Which countries have high unknown rates?
Which policies are not being matched?

Without these measurements, DNS steering becomes harder to trust.

Practical Classification Rules

A practical DNS steering system should follow these rules:

Use ECS when present and valid.
Use resolver IP when ECS is missing.
Use country for broad routing.
Use ASN for network-aware routing.
Use prefix rules only when needed.
Always check health before returning an answer.
Always define a default answer.
Log enough detail to explain decisions.
Measure unknown and fallback rates.

These rules keep requester classification useful and safe.

The Main Design Principle

The main design principle is this:

Classify the requester using the best available signal, but always assume the signal may be incomplete.

This principle prevents overconfidence.

DNS steering works in the real internet, where signals can be missing, wrong, stale, or incomplete.

The system must still return a useful answer.

How This Fits The Article Series

The earlier articles explained the foundation:

Article 1:
How authoritative DNS influences traffic direction.

Article 2:
Why DNS steering needs a control plane and data plane.

Article 3:
Why DNS steering is not load balancing.

Article 4:
Why geography, latency, and network distance are not the same.

This article explains the next layer:

How DNS steering identifies the requester before choosing an answer.

Requester classification connects theory to action.

It turns raw DNS query signals into routing context.

That context helps the system choose a safe and useful answer.

Key Takeaways

Requester classification is the process of identifying useful routing signals from a DNS query.

The authoritative DNS server usually sees the recursive resolver IP, not always the real user IP.

Country is useful for broad routing, but it is still an estimate.

ASN can improve routing because different networks in the same country may perform differently.

Network prefixes can add precision, but they need careful management.

EDNS Client Subnet can improve classification when available, but it has privacy and caching trade-offs.

The requested name and record type also matter because different services may need different routing rules.

Health must protect the final answer.

A good DNS steering system does not assume perfect information.

It uses the best available signal, applies policy, checks health, and falls back safely when data is missing.

In the next article, we will discuss EDNS Client Subnet: Powerful Signal Or Operational Trap?

Sources

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

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

IANA, Autonomous System Numbers Registry:
https://www.iana.org/assignments/as-numbers/as-numbers.xhtml

MaxMind, Geolocation Accuracy:
https://support.maxmind.com/knowledge-base/articles/maxmind-geolocation-accuracy

MaxMind, Restrictions on IP Geolocation:
https://support.maxmind.com/knowledge-base/articles/restrictions-on-ip-geolocation