Route 53 Unexpected geo location behavior

[Dan McCombs]

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
<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.
>

But that doesn't seem to be the case. On a resolver with the address
64.227.108.32, if we query at an awsdns authoritative from 64.227.108.32
without edns client subnet, we get one set of answers:

> > dig -b 64.227.108.32 @ns-1339.awsdns-39.org
> doitb-synthetic.atlassian.net +short +nosubnet

104.192.142.20
> 104.192.142.19
> 104.192.142.18


But if we send the resolver's own same IP in edns-client-subnet, we get a
different set of answers:

> >  dig -b 64.227.108.32 @ns-1339.awsdns-39.org
> doitb-synthetic.atlassian.net +short +subnet=67.227.108.32/32

104.192.138.13
> 104.192.138.12


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?

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.

Any insights would be appreciated,

-Dan


Dan McCombs
Senior Engineer I - DNS
dmccombs at digitalocean.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20230609/77fd22aa/attachment.html>