A GeoDNS authoritative server sends users in Europe to a US region when they use a distant recursive resolver; why does that happen, and how does EDNS Client Subnet change it?
answer
- whose address the server sees
- centralized resolvers far from users
- an EDNS0 option with a prefix
- source length versus scope length
- cache per client prefix
basics
~20 sGeoDNS steers by the query's source address, usually the recursive resolver's, not the user's. EDNS Client Subnet (RFC 7871) lets the resolver send a truncated client prefix and cache answers per scoped prefix, costing cache size and privacy.
solid answer
~50 sA GeoDNS authoritative server maps the source address of each query to a location, and most queries come from recursive resolvers, so it steers by the resolver's location (RFC 7871 §1). A European user of a centralized resolver whose queries leave from a US address gets the US answer, and so does everyone behind that resolver. EDNS Client Subnet, option code 8 in the EDNS0 `OPT` record, lets the resolver send `SOURCE PREFIX-LENGTH` bits of the client address, recommended /24 for IPv4 and /56 for IPv6. The server tailors the answer and returns a `SCOPE PREFIX-LENGTH` saying which network it is valid for, and the resolver caches it per prefix. The costs are more cache entries, more upstream queries, a privacy leak, and partial deployment: RFC 7871 is Informational and recommends ECS be off by default.
go deeper
Remember that a GeoDNS server sees the resolver's address, so users of a far-away resolver can be sent to a far-away region.
Explain the ECS fields, who sets each one, and how the scope decides which clients a cached answer may be reused for.
Diagnose mis-steering from resolver location, and weigh ECS's better locality against cache fragmentation, privacy exposure and partial deployment.
Decide how much steering accuracy the service needs from DNS at all, given that part of your users' resolvers will never send a client prefix.
## Why GeoDNS keys on the resolver A **GeoDNS** authoritative server tailors its answer to where a query comes from: users in Europe get the address of the Frankfurt deployment, users in North America the Virginia one. Its only built-in clue is the **source address of the query**. As RFC 7871 §1 explains, most queries arrive from recursive resolvers, so that source address is the *resolver's*, not the user's. The server maps it through its own location data, which is an implementation choice, and answers for that location. This works while the resolver sits near its users, as ISP resolvers traditionally have. It fails for **centralized resolvers** that serve users far away: a user in Lisbon whose resolver sends its queries from an address the server places in the United States gets the US region. The resolver caches that answer, and every European client behind it crosses the Atlantic for the TTL. ## What EDNS Client Subnet adds **EDNS Client Subnet (ECS)**, RFC 7871, lets a recursive resolver pass a truncated form of the client's address to the authoritative server. It rides in the EDNS0 `OPT` pseudo-record (RR type 41, RFC 6891) as option code 8. | Field | Set by | Meaning | |---|---|---| | `FAMILY` | resolver | address family: 1 = IPv4, 2 = IPv6 | | `SOURCE PREFIX-LENGTH` | resolver | how many leading bits of the client address are included | | `SCOPE PREFIX-LENGTH` | authoritative server, in the response (0 in the query) | how many bits the answer is intended for | | `ADDRESS` | resolver | the client prefix, using only as many octets as the source length needs | The exchange: 1. A client at `203.0.113.77` asks a centralized recursive resolver for `app.example.com`. 2. The resolver, with ECS enabled towards this zone, sends `FAMILY 1`, `SOURCE PREFIX-LENGTH 24`, `ADDRESS 203.0.113.0`. RFC 7871 §11.1 recommends truncating IPv4 addresses to 24 bits and IPv6 to 56. 3. The authoritative server chooses the regional answer from the client prefix, echoes `FAMILY`, `SOURCE PREFIX-LENGTH` and `ADDRESS` unchanged, and sets `SCOPE PREFIX-LENGTH`, for example 24, to say which network the answer is for. 4. The resolver caches the answer tied to that prefix (§7.3.1) and reuses it only for clients inside it; a client in another prefix causes a separate query. A `SCOPE PREFIX-LENGTH` of 0 means the answer suits every address in the family. If a query carried no ECS option, the server must not put one in its response, even when it tailored the answer by the resolver's address (§7.2.1). ## What it costs - **Cache fragmentation.** One name now has many cache entries, one per client prefix. RFC 7871 §11.3 names the memory pressure and extra upstream queries and says resolvers SHOULD limit the networks they cache per query and in total. - **Privacy.** Part of the client's address becomes visible to every server in the resolution and every network the queries cross (§11.1). The RFC recommends ECS be off by default and enabled only where it clearly helps (§2, §11.3). A client can opt out by sending `SOURCE PREFIX-LENGTH` 0. - **Partial deployment.** Many resolvers never send ECS, some deliberately for privacy, so GeoDNS still falls back to the resolver's address for their users. - **Status.** RFC 7871 is **Informational**: it documents a deployed practice, admits known shortcomings, and announces that a revised proposal would follow. It is not a Standards Track requirement. - **Where to send it.** Resolvers SHOULD be configured never to send ECS to root, TLD or public-suffix servers (§12.1), whose delegation answers do not vary by client. - **Forgery.** Anyone can put a false prefix in ECS to pollute caches or map out your steering (§11.3), so authoritative servers treat it as a hint. ## Designing for resolvers that send no ECS - Map resolver addresses deliberately; a resolver's egress address may be nowhere near its users. - Measure where users actually land against where they are, rather than trusting the location data. - Make every region acceptable from anywhere: a mis-steered user should be slow, not broken. - Treat GeoDNS as a latency optimisation, not a data-residency guarantee; a mis-mapped resolver sends users across borders. ## Interview summary GeoDNS sees the resolver, not the user, so distant centralized resolvers mis-steer. ECS carries a truncated client prefix so the authoritative server can tailor the answer, and the scope tells caches how widely to reuse it, paid for in cache size, upstream load and privacy, and only where both ends opt in.
- What should a recursive resolver do when an authoritative server returns a SCOPE PREFIX-LENGTH longer than the SOURCE PREFIX-LENGTH it sent?A longer scope says the prefix it sent was not specific enough to choose the best answer. RFC 7871 §7.2.1 says future queries for that name within that network SHOULD use the longer length, weighed against the privacy masking the operator wants and the extra cache cost. If it already sent its maximum cacheable length it caches the answer for that source prefix; otherwise §7.3.1 limits reuse to client queries carrying exactly the same source length.
- Why does RFC 7871 tell resolvers not to send ECS to root and TLD servers?Those zones are delegation-centric: their referrals are the same for every client, so the client prefix adds nothing to the answer but leaks part of the user's address. §12.1 says resolvers SHOULD be configured never to send the option to root, top-level and public-suffix servers.
saying these in an interview costs you the question
- A GeoDNS server sees the end user's address in every query
- ECS always sends the client's full IP address upstream
- ECS is a Standards Track rule every resolver implements
- The recursive resolver chooses the SCOPE PREFIX-LENGTH
- Enabling ECS costs nothing in resolver cache or upstream queries