An AI agent using a networked tool may need to resolve a hostname before it sends a request. EDNS Client Subnet (ECS) is an optional DNS extension that can reveal a truncated portion of a client’s network address to a nameserver, allowing some location-sensitive services to choose a more appropriate answer. It can also expose network information and fragment resolver caches. A safer engineering question is not simply whether ECS improves routing, but when its benefit justifies the extra disclosure.
In a typical deployment the recursive DNS resolver, not the language model, chooses whether to attach ECS information to an upstream DNS query. RFC 7871 specifies an EDNS option carrying an address family, a source prefix length, a scope prefix length and truncated address bits. Its designers explicitly identify privacy and operational shortcomings and recommend that the feature be off by default. An agent’s responsibility is to respect resolver policy, evaluate the returned answer within its real authority and avoid inventing evidence of a user location.
This guide works through exact IPv4 and IPv6 prefix calculations, the difference between the prefix sent and the prefix cached, examples of safe and unsafe cache reuse, privacy decisions, response checking and the way an automated client should respond to DNS uncertainty. All numbered network examples use documentation-only addresses; they are teaching constructions, not records of a measured live resolver or a real user.
Contents: how to read this DNS extension
Start with the DNS roles, the RFC option fields, a worked IPv4 case, a worked IPv6 case, and source versus scope. Each section stands on its own when you have a specific resolver question.
For troubleshooting continue with cache containment, privacy, zero-prefix opt-out, forwarding chains, DNSSEC boundaries, performance, negative responses and attack and cache risks.
For a practical decision use diagnostics, deployment and rollback, the independent transfer problem, answered questions, primary standards and related eduKate explanations.
The four actors and the decision each actually controls
A stub resolver is the relatively simple client-side component that begins a DNS lookup. A forwarding resolver sends the request onward. A recursive resolver obtains or caches the answer, possibly contacting authoritative servers. An authoritative nameserver holds data for the relevant DNS zone and may choose among several answers based on a client network hint. These roles are easily confused when a cloud application describes everything as its DNS service. An AI application calling a lookup API usually does not administer any of them.
Suppose a developer runs a retrieval agent that accesses an official document site. The agent may call a hostname resolution interface through its runtime. That interface can use a local cache, a corporate forwarder, a central recursive service, or an entirely managed network. The same returned address could arrive through very different chains. Do not attribute the decision to attach ECS to the agent unless the platform actually exposes that control, and do not assume the authoritative server learned the agent user’s full IP address.
ECS addresses one narrow routing issue. A central resolver might be far from the origin network of a query. An authoritative system selecting an address based only on the resolver location might return a less suitable endpoint. Sending a truncated client prefix can give a more locally relevant hint. But geographical closeness and low network latency are not identical. A nearby server can have overloaded links while a more distant one has a faster route.
The meaningful decision for an automation is whether to use the returned answer under normal DNS and service security checks. An HTTP client must still authenticate the destination according to TLS and application rules; a DNS address is not an authorisation token. A monitoring system may record that a resolver applied an ECS policy, but it should distinguish confirmed telemetry from a guess based on response time. The design starts with separated responsibilities instead of an imaginary agent controlling Internet-wide routing.
What the RFC actually carries inside one DNS option
EDNS extends the DNS protocol through an OPT pseudo-record. RFC 6891 defines the EDNS structure, and RFC 7871 defines option code 8 for Client Subnet information. The ECS option contains a two-octet option code, a two-octet option length, a two-octet address family, one octet for source prefix length, one for scope prefix length and a variable-length address field. The address field is truncated to the bits the source prefix permits. A packet capture can therefore be analysed without treating the field as a textual IP address.
An IPv4 ECS query with source prefix length 24 contains exactly three address octets because 24 divided by 8 is 3. The ECS payload contains two family octets, one source-prefix octet, one scope-prefix octet and three address octets: 2+1+1+3=7 payload octets. The option code and option length add four more octets, so this option occupies 11 octets within the larger EDNS structure. That is option size, not total DNS packet size, and not a claim about transport overhead after UDP, TCP or encryption.
For an IPv4 source prefix length 23, three octets are still needed because the ceiling of 23 divided by 8 is three. Only 23 of those 24 transmitted address bits are meaningful; the remaining bit must be zeroed. Incorrect length, nonzero padding or an unsupported address family is a malformed input concern, not a different geographic preference. RFC 7871 discusses FORMERR handling for incorrectly constructed options. Engineers should keep this binary validation separate from any higher-level decision about whether to forward the request.
The field called source prefix length describes how much address information is supplied by the query. The scope prefix length is normally zero in the query; a responding authoritative server can use it to describe the range for which its tailored answer applies. These are not two alternative spellings for the same quantity. A logging interface that merges them into one number makes downstream cache safety and privacy auditing difficult.
RFC 7871 is an informational RFC from May 2016 describing an already deployed mechanism, not an assertion that every DNS server must implement it. The document explicitly notes limitations and advises selective use. An automated implementation should negotiate the behaviour it actually encounters and be prepared for an authoritative server that ignores ECS, rather than treating lack of ECS as evidence that the domain is broken.
First worked case: one IPv4 prefix without revealing the host
Use the IPv4 documentation address 192.0.2.17. It is not a real client’s address and should never be treated as evidence about a customer. If a resolver chooses a /24 source prefix, it sends the first 24 address bits, representing network 192.0.2.0/24. The final eight host bits are omitted. An IPv4 address has 32 bits, so that prefix covers 2 to the power of (32−24), or 256 address values. That is the size of the represented range, not a claim that 256 active people share the same network.
If the resolver instead chooses /20, it keeps the first 20 bits. The containing range is 192.0.0.0/20, spanning 192.0.0.0 through 192.0.15.255. The number of possible address values is 2 to the power of 12, or 4,096. This /20 range contains sixteen distinct /24 networks because 4,096 divided by 256 equals 16. Fewer source bits mean a broader network hint and typically less address specificity, but they also reduce the authority’s ability to choose an endpoint for a narrow local route.
A decision that improves routing for one network may be unnecessary for another. A team that sees a shorter median page-load time after adding ECS must also look at outliers, cache misses, lookup failures and disclosure scope. It should compare the entire end-to-end experience: DNS, connection establishment, certificate checks, application response and content transfer. A faster DNS answer that directs a client to a failing service is not better.
For a parent or student learning networking, the key arithmetic is portable: prefix length counts address bits preserved; address-family width minus prefix length counts host bits. Do not confuse an IPv4 /24 with a fraction of 24 out of 100 people. It is 24 network bits out of 32 address bits. The notation is about addressing and routing rather than a population estimate or a permission to track individuals.
Second worked case: IPv6 privacy and a /56 network hint
IPv6 uses 128-bit addresses, and the ECS address-family field distinguishes it from IPv4. Take the documentation-only address 2001:db8:1234:56ab::1. Keeping a /56 source prefix retains three complete 16-bit hextets, which account for 48 bits, plus the next eight bits from the fourth hextet. The resulting network is 2001:db8:1234:5600::/56. The exact host suffix and the remaining low eight bits of the fourth hextet are not part of the disclosed prefix.
A /56 has 128−56=72 remaining address bits. Therefore it describes 2 to the power of 72 possible IPv6 addresses, an enormous mathematical space. That does not tell us how many devices or users occupy it. IPv6 deployments allocate prefixes according to different operational policies, and an address prefix can still function as a stable network identifier. Truncation limits what is sent but is not equivalent to anonymity.
Compare the address 2001:db8:1234:56ff::2 with the preceding example. Both share the first 56 bits, so they fall in that same /56. By contrast, 2001:db8:1234:57ab::2 differs in the first byte of the fourth hextet and falls outside it. A /48 covering 2001:db8:1234::/48 is broader than this /56 and contains 2 to the power of 8, or 256 distinct /56 subnets. This is the IPv6 counterpart of the IPv4 prefix containment exercise, but the address widths are different.
When publishing or testing a diagnostic, use reserved documentation addresses and record the family explicitly. The IPv4 documentation ranges are described in RFC 5737; 2001:db8::/32 is the IPv6 documentation prefix in RFC 3849. Do not copy a real customer’s IP prefix into a public post, ticket or classroom handout for the sake of demonstrating ECS. A useful example can be both exact and non-identifying.
The difference between source prefix and answer scope
A query’s source prefix describes the network information the resolver supplied. An answer’s scope prefix describes the network over which the authoritative server believes its answer is suitable for reuse. If the source is /24 and the response scope is /20, the server is saying that this answer is appropriate for a broader network than the one provided. A conforming cache can associate that answer with the /20 range under the relevant RFC rules, increasing potential reuse.
If the source was /24 and the answer scope /26, the authoritative server is signaling that the provided hint was too coarse for the most appropriate tailored answer. The resolver must not invent the missing two source bits. RFC 7871 has specific caching rules for this case, including restrictions on reuse, and it allows a resolver to decide whether a more specific query is justified under its own privacy cap. A server’s wish for a longer prefix does not override an upstream privacy restriction.
Scope zero is another important value. A response whose scope is /0 states that the answer can apply across the whole address family. This may permit a broad cache entry when the query and response circumstances support it. However, a cache entry created from a query that itself requested no client subnet information has a special treatment. The RFC distinguishes that entry from a broadly applicable /0 answer to an ordinary ECS query. Compressing both into one generic global-cache flag can cause incorrect reuse.
A cache has at least two relevant dimensions: expiry by DNS time-to-live and relevance to the client network. A record can be fresh in time but unsuitable for the present client’s prefix. An implementation should test both. It must also handle the case where no ECS is returned, negative responses and delegations according to the protocol, rather than pretending every DNS record is a geo-specific answer.
For readers who want one simple rule, use source prefix to ask what information went out, and scope prefix to ask where an answer may safely be used again. Neither number independently proves the answer is correct, the destination is authentic, or the service is operating.
A worked cache table in words: three users, two answers
Construct an example with three artificial IPv4 clients. Client A belongs to 192.0.2.0/24, client B belongs to 192.0.3.0/24, and client C belongs to 192.0.16.0/24. Suppose an authoritative server answers a query associated with client A and returns a scope of /23, making its answer appropriate for the containing 192.0.2.0/23 range. That /23 covers both 192.0.2.0/24 and 192.0.3.0/24, a total of 512 address values.
Under those stated conditions, the same answer may be reused for clients A and B while the DNS record remains valid, because their networks lie inside the returned /23 scope. Client C does not lie inside that range. A cache that hands client C the same answer solely because the hostname and record type match has ignored the ECS scope. A correct implementation either finds another suitable cache entry or asks an appropriate nameserver.
Now suppose the record’s remaining TTL is 30 seconds. The logical network match cannot extend that time; after expiry, a fresh lookup or some separately justified caching behaviour is needed. Conversely, a fresh record with a long TTL does not override the wrong-network problem. These are two independent checks: valid lifetime and valid subnet applicability. A third check, name and type identity, is also necessary so that an A record is not reused as an AAAA answer.
Count the potential cache partitions. A /23 contains two /24 networks, while a /20 contains sixteen /24 networks. Narrow scope can multiply cache entries, and broad scope can save work where the authoritative server truly gives the same answer. The number of actual entries depends on queries, policies and traffic, not merely on the theoretical subnet count. Measure cache footprint rather than claiming a fixed memory penalty from a prefix length alone.
This is a constructed example, not a claim that one real authoritative nameserver returns those scopes. A robust unit test can feed mocked responses with known scope values, change the simulated client prefix, and verify exactly which cache entries are permitted. That test is more convincing than visual inspection of a dashboard showing a single global hit rate.
Privacy: an address prefix is still network metadata
The central privacy trade-off is that ECS intentionally transports part of the origin network beyond the ordinary recursive resolver. Even when the exact host address is truncated, the prefix may narrow the origin to a neighbourhood, institution, household allocation or persistent network depending on address policy. Combining it with query names, timing or other data can increase linkability. The RFC calls out these concerns and recommends leaving ECS off by default, enabling it only where a clear benefit is established.
Do not confuse a /24 with a universal privacy guarantee. In one network, many users may share a public /24; in another, the same prefix may be strongly associated with an organisation. An IPv6 /56 also has many mathematical addresses, yet could correspond to a recognisable network allocation. The number of possible addresses is not the number of people hidden inside the group. A careful privacy review asks what an observer already knows and how a prefix changes that information.
An agent application should use the DNS platform’s controls rather than trying to collect raw client addresses for its own routing experiments. In particular, a model does not need full resolver logs to answer a user’s learning question. Prefer aggregate performance and error measurements, remove unnecessary identifiers and define retention windows before turning on telemetry. A test designed to help a handful of pages load faster should not silently become a long-term identity or location tracking mechanism.
RFC 7871 explicitly discourages making ECS a default in nameserver software. It also provides an anonymity signal through source prefix length zero, subject to the actual resolver chain’s support. The default choice for a system owner should be to avoid extra disclosure unless measured benefit and informed governance justify it. Privacy is part of the technical specification, not a compliance paragraph added after deployment.
When a user’s actual address matters for a separate application function, ECS does not substitute for direct user consent or the service’s proper authority to process that information. It is a DNS routing hint. It should not be stretched into an employee attendance log, learner location test, identity verifier or entitlement decision.
A source prefix of zero is an instruction with consequences
RFC 7871 allows a stub resolver to send an ECS option with source prefix length zero. This indicates that the recursive resolver must not add the client’s address information to the queries it originates for that request. It is a limitation on disclosure, not a request to send the entire address in zero additional bytes. The option still uses its address-family field and other protocol structure, but supplies no origin subnet bits.
Forwarders and recursive resolvers must respect an incoming restriction. If a downstream server asks for a /0 source, an upstream resolver cannot permissibly expand it to a /24 simply because a nearby CDN likes narrow traffic steering. A user preference would mean little if every intermediate hop could reverse it without consent. An implementation should include tests in which a query passes through one or more forwarders and preserve the restriction end to end.
The source-zero rule also requires thought at the cache. An answer obtained for a privacy-restricted /0 request cannot automatically be treated as a geographic answer for every other client merely because the client subnet field was absent. RFC 7871 distinguishes the two meanings of a /0 cache record: a no-subnet query and a response explicitly scoped to all clients. Read the relevant cache provisions before compressing them into a single SQL column or key-value-store entry.
If a server cannot honour the combination of client restrictions and local policy, refusing or using an unpersonalised route may be preferable to silently exposing a more specific prefix. The right behaviour depends on DNS role and supported protocol, but the invariant is to avoid increasing disclosed client information contrary to the incoming constraint. Document the operational fallback so that availability problems do not become covert privacy exceptions.
What forwarding chains can and cannot promise
An ECS-aware query may pass from an endpoint stub resolver through a corporate forwarder and a public recursive service before reaching an authoritative server. Each boundary can have its own maximum permitted source prefix. RFC 7871 addresses restrictions on propagation and permits intermediate resolvers to shorten an incoming prefix. The fact that one resolver supports ECS does not prove every other hop will pass it through, or that the nameserver’s returned answer used the hint.
Suppose a child resolver receives an IPv4 /28 prefix while the organisation’s outward policy caps disclosure at /20. The outward query may reveal at most /20, not /28, because /20 preserves fewer address bits. If the incoming query explicitly capped disclosure at /16, the resolver cannot increase it to /20. For this family of prefix lengths, smaller numbers represent broader networks and fewer preserved address bits. Developers sometimes reverse this relationship while writing policy conditions.
A forwarding chain also creates a responsibility to handle unsupported options. A server may ignore ECS entirely or return an error for malformed data. The application should not interpret the absence of a personalised answer as DNSSEC failure or as proof of an attack. Standard DNS resolution, appropriate retries and documented fallbacks continue to matter. If the target is a service with security requirements, those are checked independently after DNS.
A decision record should identify who administers the stub, forwarder, recursive resolver and authoritative service, and which interface allows safe configuration. Many AI agents have none of these privileges. Their correct behaviour is to use the configured resolver and preserve evidence of a lookup result, not to improvise new privileged network controls in response to a slow answer.
Test the full chain with authorised tooling and synthetic source prefixes, not by transmitting unrelated users’ addresses to unknown hosts. A good test plan proves the maximum disclosed bits, whether opt-out propagates, whether responses match requests and whether cache scoping is respected on every supported address family.
ECS is not DNSSEC and it does not authenticate a destination
DNSSEC is concerned with cryptographic authentication of DNS data and the trust chain for signed records. ECS conveys network-selection metadata and response scope. A response may be correctly signed yet direct different client subnets to different address records under an authorised DNS policy. Conversely, ECS fields in a request do not make an unsigned answer authentic. The two mechanisms answer different questions and should be monitored with different success criteria.
A safe lookup pipeline separates DNS response validation from application identity verification. If a user-facing agent is going to fetch information from a website, the client still validates the HTTPS certificate and origin according to the actual HTTP and TLS security model. Obtaining an address through an ECS-informed DNS answer neither grants permission to access the site nor authorises the agent to send private information to it.
A practical incident analysis might see a sudden change in which CDN endpoint a client receives. The first diagnostic question is whether DNS name, type, source hint, returned scope, TTL and resolver path explain the difference. The next questions cover signed DNS data, TLS identity and application health. Bundling them into one vague trust score hides the place that actually failed. A route can be valid but slow; an identity check can fail on a route that is fast.
Readers who need deeper security mechanisms can consult the already published eduKate guide to DNSSEC validation and signed denials and the separate guide to DANE TLSA certificate identity. Those are contextual routes, not synonyms or replacements for ECS’s privacy and cache-scope problem.
Why a more local DNS answer may still be worse
Location-sensitive authoritative DNS systems may choose a CDN edge or service endpoint based on the origin network hint. That can improve performance if the chosen route corresponds to real network conditions. But path quality depends on interconnection, congestion, maintenance, provider topology and server load, not simply the number of kilometres between two locations. DNS topology changes independently of administrative geography.
Imagine two candidate endpoints. Endpoint A is 40 kilometres away but requires a congested transit path of 85 milliseconds measured median round-trip time. Endpoint B is 800 kilometres away yet has a better interconnection with a measured median of 28 milliseconds. The shorter geographic distance is not evidence that A is faster. These numerical values are made up to expose the reasoning error; a real operational decision needs observed routes and consistent measurement conditions.
Suppose a service performs 100 requests under policy A and another 100 under policy B. Averages alone are inadequate when a few requests time out. Measure the proportion completing within the user’s deadline, median and tail response time, DNS lookup failures, cache hits and service errors. Keep client populations comparable. If one group consists mainly of office machines on fibre links while another uses mobile roaming networks, the observed difference cannot be attributed to ECS alone.
An honest performance conclusion may be that ECS helped one region but harmed another, or that a generic resolver performed almost as well without extra disclosure. Deployment should be reversible and measured. The word optimisation refers to an objective and constraints: faster qualified transactions at an acceptable privacy and reliability cost, not maximum geographic precision for its own sake.
Negative answers, delegations and a boundary many caches miss
Some DNS responses say that the requested name or record does not exist. Others involve delegations or CNAME chains that lead to further queries. RFC 7871 discusses handling of these cases because not every piece of a DNS message is appropriately tied to the same network prefix. An implementation that tags an entire mixed response with one arbitrary scope can over-restrict useful records or, worse, reuse tailored address information outside its intended range.
A CNAME can point from an alias to another hostname whose address answer has a different scope. A resolver must follow the DNS semantics while respecting appropriate ECS caching boundaries; this is more subtle than storing a one-line hostname-to-IP dictionary. A correct unit test can deliberately return an alias and then different scoped address answers from distinct authority stages to reveal whether the cache separation survives the chain.
Negative caching has its own DNS rules. The absence of a service record may be authoritative and time-limited, and it can also be sensitive to policy. Do not invent a universal instruction to strip ECS from every negative response, or to apply the same cache key to all message sections. Read the RFC’s distinct treatment of answer, authority and additional data, and test unsupported or unexpected combinations conservatively.
For an agent, the practical response to a valid negative DNS answer is not to hallucinate an alternative hostname or silently contact a different domain. It should report the lookup result under the rules of its task, distinguish retryable temporary errors from actual negative answers, and preserve authentication checks on any permitted fallback. Correctly handling the unexpected is part of reliable automation.
Misuse, spoofing and cache pollution are distinct from privacy loss
EDNS options are protocol fields, and RFC 7871 identifies malicious or malformed uses such as cache pollution and amplification of resource consumption. A response that claims to be associated with one ECS query should preserve required family and source-prefix information according to the protocol checks. A resolver that accepts mismatched ECS fields may associate the answer with the wrong client network and hand later clients a response selected for a different region.
The attacker model matters. One threat is passive network-information disclosure to parties who otherwise would not receive it. Another is an active attempt to cause a resolver to cache unsuitable answers. A third is resource exhaustion caused by forcing many narrowly scoped cache entries. A general statement that ECS makes DNS insecure collapses these different mechanisms and provides little repair guidance. Name which adversary, field and trust boundary the mitigation addresses.
A defensive test can feed malformed ECS option lengths, unsupported address families, nonzero padding beyond a declared prefix and replies with inconsistent source fields. The expected outcomes should come from protocol rules and the resolver’s documented policies. The test does not require crafting real attacks against outside infrastructure; it can be run against a local test harness with synthetic messages.
Security claims also need narrow wording. ECS does not replace request signatures, TLS, DNSSEC or access-control checks. A successful cache-key unit test is not a penetration test. A good engineering write-up states what was tested, what was not, and how an operator can detect anomalous cache cardinality or unexpected source-prefix changes without logging unnecessary user identifiers.
A privacy-preserving diagnostic record for an agent platform
A useful DNS reliability record can include the queried domain under an approved retention policy, requested record type, resolver identity or deployment version, whether ECS was enabled, requested source prefix length, returned scope length, cache-hit category, response code and total resolution duration. It does not automatically need a full client address or a public trace containing the truncated prefix. Metadata collection must have an actual debugging purpose and appropriate access restrictions.
Consider measuring 2,000 authorised lookups in an isolated test population. A monitoring summary reports 1,620 responses served from cache, so the cache-hit proportion is 1,620/2,000=81%. Of the 380 misses, 12 exceed a defined 200-millisecond DNS deadline, so the miss deadline-failure proportion is 12/380, about 3.16%. The overall proportion of all requests exceeding that deadline is 12/2,000=0.6% if those are the only late requests. The denominators answer different operational questions.
Privacy impact is not captured by hit rate alone. An operator can measure how many queries disclose a nonzero prefix, which prefix-length policy was used and what share of lookups would succeed without ECS. These aggregates can be computed with controls that avoid retaining address identities in ordinary logs. If detailed diagnostic prefixes are temporarily needed for a specific incident, set a narrow access policy and a deletion deadline instead of creating an indefinite data lake.
Attach time information to every observation. DNS TTL and resolver configuration changes can alter behaviour across a day; a simple before-and-after comparison may be confounded by unrelated CDN deployments or traffic shifts. A deployment record should include start time, software versions, policy changes and rollback thresholds. Report what was measured, not what a dashboard colour implies.
For agents that only consume DNS through a provider interface, do not pretend they measured hidden resolver internals. If the provider exposes only final answers and wall-clock latency, report just those facts. Reliable explanations preserve the boundary between observable evidence and architectural assumptions.
Deciding whether ECS belongs in a production resolver policy
The first deployment question is whether the team has demonstrated a location-sensitive DNS problem that cannot be acceptably solved without disclosing client prefix information. If the evidence is only a theoretical possibility of faster routing, leave ECS disabled. RFC 7871’s privacy note explicitly advises default-off operation, and it is reasonable for an agent platform to inherit that conservative default.
If a narrower test is justified, identify exactly which authoritative services require the hint, which network ranges may be disclosed, which clients have an opt-out route, and which resolver configurations will be changed. Do not broaden the setting globally simply because one service benefits. Establish an approval boundary, monitoring plan, expiry date for the experiment and a way to return to normal resolution when the benefit is not confirmed.
The test plan should compare DNS answer correctness, cache reuse, latency, destination health and privacy effects with and without ECS on like-for-like traffic. If a vendor claims a performance gain, ask for the metric definition, sample size, network conditions and practical effect on users. No DNS feature deserves credit for improved learning, business value or safety unless those outcomes were independently assessed in the actual application.
A rollback is more than flipping a checkbox. Existing caches may contain scoped answers with finite TTLs, and propagation across forwarding chains may not be immediate. The operator should verify the effective policy after rollback, inspect whether new queries are still carrying ECS and confirm that response handling remains safe while older entries expire under documented rules.
An AI assistant should never unilaterally change company resolver settings just because a single lookup was slow. It can explain the evidence needed, recommend an authorised escalation and avoid making a network-wide privacy decision outside its permitted scope. That is a realistic engineering meaning of safe agency, independent of speculation about hypothetical superintelligent systems.
Changed-context transfer: a scope mismatch across two offices
Work this problem before reading the solution. A resolver sends an IPv4 ECS source prefix of /24 for synthetic office X at 192.0.2.0/24. The authoritative response states scope /23 and has 45 seconds of TTL remaining. Office Y uses 192.0.3.0/24. Office Z uses 192.0.4.0/24. Assuming the answer is otherwise valid, which office can reuse the scoped cached answer, and why? What changes when the TTL reaches zero?
The /23 containing 192.0.2.0 spans 192.0.2.0 through 192.0.3.255. Office Y is inside this range, so the answer can be reused for that network under the stated scope rule while it remains valid. Office Z is outside and needs a different suitable cache entry or a fresh authoritative lookup. After the remaining 45 seconds elapse, the answer no longer passes the ordinary DNS lifetime check for either office, regardless of whether the source prefix matches.
Now change the case again. Instead of a response scope /23, suppose the authoritative server states scope /25 after receiving a /24 query. This means the supplied prefix was not detailed enough to identify the ideal narrow response. The resolver must not infer which half of the /24 contains the actual user merely from the ECS field it sent. Its response and cache policy must follow the more restrictive RFC case, and it must not expose additional bits beyond an upstream privacy cap just to pursue a finer answer.
A final distinction: if office X originally requested a source prefix of zero as a privacy restriction, none of the other assumptions about disclosed /24 client prefixes applies. Revisit the cache entry type and verify whether the response was broad enough for other clients under the RFC’s rules. The test checks that a learner can transfer the source-versus-scope distinction rather than memorise the result for one pair of numbers.
Mark these addresses as constructed documentation ranges. The example teaches CIDR containment, cache authority and time validity, not live network behaviour. A tested production implementation would need packet-level evidence, authoritative server policy and timestamps before asserting that such reuse actually occurred.
Frequently asked questions
Can the AI model itself send ECS?
Only if the application or a permitted networking interface actually constructs or configures ECS-bearing DNS queries. Usually the DNS resolver makes that choice. A language model’s text about a prefix is not evidence of network behaviour. Preserve the platform’s authority boundary.
Does a /24 prefix anonymise the client?
Not reliably. It omits the final eight IPv4 host bits but still identifies a network range, and the number of active people in that range is unknown. Linkability depends on other information, allocation patterns and retention. Treat the prefix as potentially sensitive metadata.
Is RFC 7871 a mandatory Internet standard?
No. RFC 7871 was published in May 2016 as an informational specification describing an already deployed extension. The document explicitly notes operational and privacy limitations and recommends default-off treatment. Support and policies vary by operator.
Why does the response carry a scope prefix?
It tells a caching resolver which network range the authoritative server intends its answer to apply to. A broader scope can permit reuse; a narrower scope may require more specific information for the ideal answer. The cache must apply the detailed RFC rules, including zero-source edge cases.
Is a zero source prefix the same as a universal cached answer?
No. A request with source prefix length zero restricts disclosure of client subnet information. RFC 7871 distinguishes the resulting cache entry from a response whose scope zero explicitly makes the answer suitable for every network in the family. Do not collapse those semantics.
Can ECS verify that a website is trusted?
No. ECS is a routing hint and cache-scoping extension. DNSSEC validation, TLS authentication, application authorisation and response-content evaluation remain separate. A locally selected IP address is not an access credential.
Why could enabling ECS reduce cache hits?
A response can become associated with one or more network-specific scopes rather than a single global hostname record. A cache may then need additional entries and misses for other client prefixes. The actual effect depends on response scopes and traffic, so measure rather than guess.
Should ECS be turned on for every automated browser?
Not by default. The RFC recommends the mechanism be off unless an operator has a clear benefit case. A browser or agent should normally respect the configured resolver and security controls, not collect additional client addresses or override privacy policy.
How can I test the prefix arithmetic safely?
Use IPv4 documentation ranges such as 192.0.2.0/24 and the IPv6 documentation prefix 2001:db8::/32. Calculate preserved bits, omitted bits and containing networks, then test a local mock cache. Avoid publishing real customer addresses.
What is the first useful repair after an ECS-related DNS incident?
Identify whether the failure concerns disclosure, malformed options, inappropriate answer scope, cache lifetime, genuine negative DNS response or destination health. Inspect authorised telemetry and reproduce with synthetic prefixes. Do not respond to a slow DNS answer by weakening TLS or blindly adding more client address bits.
Authoritative sources and dates
Primary protocol: RFC 7871, Client Subnet in DNS Queries (May 2016). The document is informational and includes the exact option format, request and response prefix fields, cache rules, opt-out provisions and security and privacy notes.
Underlying DNS extension: RFC 6891, Extension Mechanisms for DNS (EDNS(0)) (April 2013), which defines the OPT pseudo-record carrying options such as ECS.
Documentation address sources: RFC 5737, IPv4 Address Blocks Reserved for Documentation and RFC 3849, IPv6 Address Prefix Reserved for Documentation. All numerical network examples above deliberately use these prefixes.
Operational context from a service developer: Cloudflare One documentation on testing EDNS Client Subnet DNS behaviour. Provider-specific configurations are examples, not universal DNS standards. Check current vendor documentation when administering a real resolver.
Further reading and reader pathways
The wider How Super Intelligence Works guide explains agent responsibilities, tool boundaries and human control. It does not imply that artificial superintelligence currently exists.
For cryptographic integrity in a DNS lookup, follow Agent DNSSEC Validation. For certificate-related nameservice checks, follow Agent DANE TLSA Identity. These are separate from the ECS routing and privacy job.
Try teaching the topic to another reader using one /24 query and one /23 scope response. Explain how many IPv4 addresses are in each, which client prefixes share a cache entry, which bits leave the resolver, and which security checks remain independent. If the explanation does not distinguish source prefix and scope prefix, the central mechanism is not yet secure.