[dns-operations] Route 53 Unexpected geo location behavior

[Robert Edmonds]

Dan McCombs via dns-operations wrote:
> Hi everyone,
> 
> We've stumbled upon what seems like unexpected behavior with Route 53 returning
> answers based on IP geo location to our resolvers.
> 
> According to their documentation:
> 
>     When a browser or other viewer uses a DNS resolver that does not support
>     edns-client-subnet, Route 53 uses the source IP address of the DNS resolver
>     to approximate the location of the user and responds to geolocation queries
>     with the DNS record for the resolver's location.

Here is the page that text is from, and the description of the other
case (when a resolver does send an EDNS Client Subnet payload):

    https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-edns0.html

    When a browser or other viewer uses a DNS resolver that does not
    support edns-client-subnet, Route 53 uses the source IP address of
    the DNS resolver to approximate the location of the user and
    responds to geolocation queries with the DNS record for the
    resolver's location.

    When a browser or other viewer uses a DNS resolver that does support
    edns-client-subnet, the DNS resolver sends Route 53 a truncated
    version of the user's IP address. Route 53 determines the location
    of the user based on the truncated IP address rather than the source
    IP address of the DNS resolver; this typically provides a more
    accurate estimate of the user's location. Route 53 then responds to
    geolocation queries with the DNS record for the user's location.

That text seems to be entirely consistent with nameserver behavior that
sends different records to a resolver when it supplies its own IP
address (or its own subnet) via the ECS option versus when it does not,
because the resolver is asking for two different things. In the former
case, the resolver is asking for responses tailored to a precise IP (or
a precise subnet). In the latter case, the resolver is asking for
responses on behalf of the whole client population that utilizes the
resolver. These are not necessarily the same.

> If it were using the resolver's source IP address to determine geolocation when
> no edns-client-subnet is sent, I would expect the same answers as when sending
> that address as the edns-client-subnet. What's going on here?

I don't see anything in these DNS responses that is inconsistent with
their documentation, or with the ECS specification. If there is a
performance issue with one set of records versus another (you don't
really say why the differing responses matter in your email), you might
try contacting the nameserver operator directly to discuss the issue.

> Our resolvers are co-located with our user's instances in the same datacenters,
> so we don't configure our resolvers to send edns-client-subnet since they're
> not geographically different (and in fact in the same IP blocks). This is the
> first time we've had a user contact us about this, so I'm not sure if something
> changed with Route 53 recently, if this is being caused by configuration
> specific to the atlassian.net zone, or if somehow we just haven't had users
> notice that they were being affected by this for years.

There are many ways for operators of ECS-enabled nameservers to decide
how to tailor DNS responses when receiving an ECS-enabled query.
Geolocation, network topology, and actual performance may all be
relevant. Even if your resolver instances are receiving queries from
customer instances located in the same physical data center, those
customer instances may themselves be forwarding traffic from eyeballs
located further away (e.g.: https://www.digitalocean.com/solutions/vpn).
A data-driven approach on the part of the nameserver operator could
plausibly choose to send different kinds of responses to resolvers that
are serving eyeballs that are dispersed over a larger catchment area.

-- 
Robert Edmonds