<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> If there is a performance issue with one set of records versus another (you don't<br>really say why the differing responses matter in your email), you might<br>try contacting the nameserver operator directly to discuss the issue.<br clear="all"></blockquote><div><br>Ah, yes, so in this case the addresses given back when no edns subnet is provided are the addresses of servers in eu-west, whereas with the resolver's own IP (or /24 subnet, or the subnet of clients querying it) as the edns subnet gets more expected us-west responses since this resolver and clients are in San Francisco.<br><br>When contacting Atlassian, they seemed to shrug it off as Route 53 behavior rather than something they control, so I'm curious if any Route 53 folks are here and could say whether this is expected behavior or not, or if this could be something with Atlassian's DNS configuration in their Route 53 service.<br><br>Thanks,<br><br>-Dan<br> </div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><table width="100%" style="font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:15px;line-height:22px"><tbody><tr><td width="55px" valign="top" style="padding-right:12px"><br><img src="https://digitaloceanspace.nyc3.digitaloceanspaces.com/do-sig_files/do-email_signature.png" style="width:50px"></td><td><div style="color:rgb(34,34,34);font-weight:bold;margin-top:4px"><br>Dan McCombs</div><div style="color:rgb(34,34,34);margin-bottom:12px">Senior Engineer I - DNS</div><div><a href="mailto:dmccombs@digitalocean.com" style="color:rgba(51,51,51,0.75);font-size:14px" target="_blank">dmccombs@digitalocean.com</a></div></td></tr></tbody></table></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 10, 2023 at 3:59 PM Robert Edmonds <<a href="mailto:edmonds@mycre.ws">edmonds@mycre.ws</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dan McCombs via dns-operations wrote:<br>
> Hi everyone,<br>
> <br>
> We've stumbled upon what seems like unexpected behavior with Route 53 returning<br>
> answers based on IP geo location to our resolvers.<br>
> <br>
> According to their documentation:<br>
> <br>
> When a browser or other viewer uses a DNS resolver that does not support<br>
> edns-client-subnet, Route 53 uses the source IP address of the DNS resolver<br>
> to approximate the location of the user and responds to geolocation queries<br>
> with the DNS record for the resolver's location.<br>
<br>
Here is the page that text is from, and the description of the other<br>
case (when a resolver does send an EDNS Client Subnet payload):<br>
<br>
<a href="https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-edns0.html" rel="noreferrer" target="_blank">https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-edns0.html</a><br>
<br>
When a browser or other viewer uses a DNS resolver that does not<br>
support edns-client-subnet, Route 53 uses the source IP address of<br>
the DNS resolver to approximate the location of the user and<br>
responds to geolocation queries with the DNS record for the<br>
resolver's location.<br>
<br>
When a browser or other viewer uses a DNS resolver that does support<br>
edns-client-subnet, the DNS resolver sends Route 53 a truncated<br>
version of the user's IP address. Route 53 determines the location<br>
of the user based on the truncated IP address rather than the source<br>
IP address of the DNS resolver; this typically provides a more<br>
accurate estimate of the user's location. Route 53 then responds to<br>
geolocation queries with the DNS record for the user's location.<br>
<br>
That text seems to be entirely consistent with nameserver behavior that<br>
sends different records to a resolver when it supplies its own IP<br>
address (or its own subnet) via the ECS option versus when it does not,<br>
because the resolver is asking for two different things. In the former<br>
case, the resolver is asking for responses tailored to a precise IP (or<br>
a precise subnet). In the latter case, the resolver is asking for<br>
responses on behalf of the whole client population that utilizes the<br>
resolver. These are not necessarily the same.<br>
<br>
> If it were using the resolver's source IP address to determine geolocation when<br>
> no edns-client-subnet is sent, I would expect the same answers as when sending<br>
> that address as the edns-client-subnet. What's going on here?<br>
<br>
I don't see anything in these DNS responses that is inconsistent with<br>
their documentation, or with the ECS specification. If there is a<br>
performance issue with one set of records versus another (you don't<br>
really say why the differing responses matter in your email), you might<br>
try contacting the nameserver operator directly to discuss the issue.<br>
<br>
> Our resolvers are co-located with our user's instances in the same datacenters,<br>
> so we don't configure our resolvers to send edns-client-subnet since they're<br>
> not geographically different (and in fact in the same IP blocks). This is the<br>
> first time we've had a user contact us about this, so I'm not sure if something<br>
> changed with Route 53 recently, if this is being caused by configuration<br>
> specific to the <a href="http://atlassian.net" rel="noreferrer" target="_blank">atlassian.net</a> zone, or if somehow we just haven't had users<br>
> notice that they were being affected by this for years.<br>
<br>
There are many ways for operators of ECS-enabled nameservers to decide<br>
how to tailor DNS responses when receiving an ECS-enabled query.<br>
Geolocation, network topology, and actual performance may all be<br>
relevant. Even if your resolver instances are receiving queries from<br>
customer instances located in the same physical data center, those<br>
customer instances may themselves be forwarding traffic from eyeballs<br>
located further away (e.g.: <a href="https://www.digitalocean.com/solutions/vpn" rel="noreferrer" target="_blank">https://www.digitalocean.com/solutions/vpn</a>).<br>
A data-driven approach on the part of the nameserver operator could<br>
plausibly choose to send different kinds of responses to resolvers that<br>
are serving eyeballs that are dispersed over a larger catchment area.<br>
<br>
-- <br>
Robert Edmonds<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div>