[dns-operations] EDNS client-subnet best practice?

[Reed, Jon]

Hi Chris,

> What is considered current best practice for recursive servers on
> enabling EDNS client-subnet?

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.

> 
> I ask because I have a couple of recursive DNS servers at an independent
> telephone company that are getting different answers for a certain large
> website.  The servers are in the same subnet, but one gets an IP
> apparently in another country, while the other gets an IP in a nearby
> state.  The servers are configured identically (CentOS 7 with Unbound).
> 
> I emailed the website's NOC, and their response was that the issue was
> that "Most likely the issue is due to EDNS not being turned on with your
> DNS server."  I assume they were talking about EDNS client-subnet
> (because they then gave an example dig with +subnet set).
> 
> These servers are not configured to send client-subnet to anybody
> (pretty much default Unbound config).  They aren't serving clients from
> outside the AS - I generally think of client-subnet as something you'd
> use on a DNS server with a wide range of clients.  Is it expected that I
> should be enabling EDNS client-subnet on recursive servers?

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.

> 
> I do have some recursive servers that have a large set of clients (where
> client-subnet might be useful) - should I just enable it for all
> requests?  In Unbound terms, enable "client-subnet-always-forward"?

It does sound like ECS would be useful in this case.  https://tools.ietf.org/html/rfc7871#section-11 <https://tools.ietf.org/html/rfc7871#section-11> 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.

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. 

-Jon

[1] In the event the NOC in question was Akamai, feel free to follow up with me off-list.

[2] https://dl.acm.org/doi/10.1145/3355369.3355586 <https://dl.acm.org/doi/10.1145/3355369.3355586>

--
Jon Reed
jreed at akamai.com
Senior Architect
Akamai Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200603/e7f3213c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2986 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20200603/e7f3213c/attachment.bin>