<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Chris,<div class=""><div class=""><div class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><br class=""></div></div></div><div><blockquote type="cite" class="">What is considered current best practice for recursive servers on<br class=""><div class=""><div class="">enabling EDNS client-subnet?<br class=""></div></div></blockquote><div><br class=""></div><div>I think you'll get a variety of different answers to this question (including "never ever enable it"), but I'll offer my views below.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">I ask because I have a couple of recursive DNS servers at an independent<br class="">telephone company that are getting different answers for a certain large<br class="">website.  The servers are in the same subnet, but one gets an IP<br class="">apparently in another country, while the other gets an IP in a nearby<br class="">state.  The servers are configured identically (CentOS 7 with Unbound).<br class=""><br class="">I emailed the website's NOC, and their response was that the issue was<br class="">that "Most likely the issue is due to EDNS not being turned on with your<br class="">DNS server."  I assume they were talking about EDNS client-subnet<br class="">(because they then gave an example dig with +subnet set).<br class=""><br class="">These servers are not configured to send client-subnet to anybody<br class="">(pretty much default Unbound config).  They aren't serving clients from<br class="">outside the AS - I generally think of client-subnet as something you'd<br class="">use on a DNS server with a wide range of clients.  Is it expected that I<br class="">should be enabling EDNS client-subnet on recursive servers?<br class=""></div></div></blockquote><div><br class=""></div><div><div class="">The behavior you describe seems more like incorrect geolocation rather than an issue that EDNS0 Client Subnet (ECS) could solve.  ECS was intended to solve the case where the end-users behind a resolver are in a different "place" (geographically or topologically) than the resolver itself.  That's not the same thing as two resolvers in the same subnet (assuming you mean something relatively small, like a /24) getting consistently different answers.  (I assume the one resolver always gets the wrong answer, such that you've ruled out some sort of round-robin behavior).  It may be worth following up[1] and asking them where they think your IPs are located.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">I do have some recursive servers that have a large set of clients (where<br class="">client-subnet might be useful) - should I just enable it for all<br class="">requests?  In Unbound terms, enable "client-subnet-always-forward"?<br class=""></div></div></blockquote><div><br class=""></div><div>It does sound like ECS would be useful in this case.  <a href="https://tools.ietf.org/html/rfc7871#section-11" class="">https://tools.ietf.org/html/rfc7871#section-11</a> describes best practices around setting the source prefix to balance user privacy with functionality.  I don't know the specific Unbound settings off the top of my head that correspond to those, but I believe they're configurable, but also that the default values are in line with those recommended by the RFC.</div><div><br class=""></div><div>Since we're long past 2019's DNS Flag Day, you shouldn't have a problem with authorities misbehaving because they don't understand ECS, but I would recommend keeping an eye on logs of authoritative failures, as there are still likely a few misbehaving servers out there.  My colleague Kyle Schomp recently collaborated on a paper[2] discussing some pitfalls of incorrectly configured ECS setups, if you want to read through it. </div><div><br class=""></div><div>-Jon</div><div><br class=""></div><div>[1] In the event the NOC in question was Akamai, feel free to follow up with me off-list.</div><div><br class=""></div><div>[2] <a href="https://dl.acm.org/doi/10.1145/3355369.3355586" class="">https://dl.acm.org/doi/10.1145/3355369.3355586</a></div></div><br class=""></div></div><div class=""><br class=""></div><div class="">--</div><div class="">Jon Reed<br class=""><a href="mailto:jreed@akamai.com" class="">jreed@akamai.com</a><br class="">Senior Architect<br class="">Akamai Technologies</div></body></html>