[dns-operations] Route 53 Unexpected geo location behavior

[Dan McCombs]

Oops, thanks Crist. Yes, that was a typo in my example and this
inconsistency does happen even when it's correct. 😄

I retested for good measure:

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

104.192.142.19
> 104.192.142.20
> 104.192.142.18


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

104.192.138.12
> 104.192.138.13


Thanks,

-Dan


Dan McCombs
Senior Engineer I - DNS
dmccombs at digitalocean.com


On Fri, Jun 9, 2023 at 11:57 PM Crist Clark <yheffen at gmail.com> wrote:

> Well, in your example below, looks like a typo. You have the first octet
> in the subnet option set to 67, when it’s 64 for the server.
>
> Is that just a typo in the example below? Do you still see inconsistencies
> when it’s correct?
>
>
> On Fri, Jun 9, 2023 at 2:25 PM Dan McCombs via dns-operations <
> dns-operations at dns-oarc.net> wrote:
>
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Dan McCombs <dmccombs at digitalocean.com>
>> To: dns-operations at lists.dns-oarc.net
>> Cc:
>> Bcc:
>> Date: Fri, 9 Jun 2023 16:58:51 -0400
>> Subject: Route 53 Unexpected geo location behavior
>> 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
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Dan McCombs via dns-operations <dns-operations at dns-oarc.net>
>> To: dns-operations at lists.dns-oarc.net
>> Cc:
>> Bcc:
>> Date: Fri, 9 Jun 2023 16:58:51 -0400
>> Subject: [dns-operations] Route 53 Unexpected geo location behavior
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20230610/edab8c2b/attachment.html>