Todo #13456
closed
Feedback on pfSense® software Configuration Recipes — Configuring DNS over TLS
100%
Description
Page: https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html
Feedback:
For the "Enable DNS over TLS Server (optional)" section (at the end):
1) The use of "must" is too strong in this sentence "Only enable this feature if local clients must talk to the DNS Resolver using DNS over TLS queries." That may scare people away from enabling it, and really it should be encouraged to turn this on.
2) I would suggest also adding a sentence like: "DoT is supported by iOS 14, macOS 11 Big Sur, Android 9 (Pie), and systemd-resolved (not sure of version)."
3) The sentence "Now the DNS Resolver will listen for DNS over TLS queries from local clients on port 853." would be better if it said "*TCP* port 853" (as opposed to UDP, like plain old DNS).
but most importantly:
4) It should address https://redmine.pfsense.org/issues/13454 and https://redmine.pfsense.org/issues/13393 That is, it should say that one must not select "All" for the network interfaces.
Updated by Chris W over 2 years ago
https://gitlab.netgate.com/docs/pfSense-docs/-/merge_requests/53
Regarding the list points:
1) The word "must" is consistent with IETF requirement level terminology and is technically accurate for the given scenario:
https://www.ietf.org/rfc/rfc2119.txt
2) The end user would be the most appropriate place of responsibility for verifying whether their specific operating system, browser, DNS manager/app, etc. supports DoT.
3) Done.
4) Done.
Updated by Chris W over 2 years ago
- Status changed from New to Pull Request Review
Updated by Sean McBride over 2 years ago
For 1) It's true that if any of one's local clients MUST talk to the DNS Resolver using DoT then one MUST enable this feature. But that's not the ONLY reason to turn it on. One might also want to turn it on if some local clients optionally talk DoT. Realistically, that's most networks today. Few things require DoT, some things support it optionally, some don't support it at all.
I feel strongly pfsense users should be encouraged to turn DoT on for local clients, so that those clients that support it can use it.
Concretely, I suggest changing from:
"Only enable this feature if local clients must talk to the DNS Resolver using DNS over TLS queries."
to:
"Enable this feature if any of your local clients are able to talk to the DNS Resolver using DNS over TLS queries."
Clients that "are able to talk" are a superset of those that "MUST talk", so this is still technically correct.
or if you really want to keep the word "must" in there:
"Enable this feature if any local clients must talk to the DNS Resolver using DNS over TLS queries, or if some local clients can optionally"
But please at least get rid of the first word "only".
For 2) I don't feel so strongly about this one, but I'll note the article says further up "Pick a DNS over TLS upstream provider, such as a private upstream DNS server or a public service like Cloudflare, Quad9, or Google public DNS." Why call out those specific companies? Surely "the end user would be the most appropriate place of responsibility for verifying whether their specific upstream provider supports DoT"?
Those handful of companies are called out, presumably, because a lot of people use them. Likewise, a lot of people use just a handful of OSes, and calling out their level of DoT support seems likewise helpful.
For 3 & 4) thanks for fixing them. That gitlab.netgate.com link does not work though, so I can't review what you did. Is your gitlab down currently?
Updated by Jim Pingle over 1 year ago
- Status changed from Pull Request Review to Closed
- Assignee set to Jim Pingle
- % Done changed from 90 to 100
Sean McBride wrote in #note-4:
For 1) It's true that if any of one's local clients MUST talk to the DNS Resolver using DoT then one MUST enable this feature. But that's not the ONLY reason to turn it on. One might also want to turn it on if some local clients optionally talk DoT. Realistically, that's most networks today. Few things require DoT, some things support it optionally, some don't support it at all.
You're reading the "must" there a bit backwards. It's not saying if all your clients have to use it, it's saying that for a client to use DoT the feature must be enabled.
It doesn't matter if it's one client or all of them, optionally or required by client software, if any client must be able to use DoT to reach the resolver, it has to be enabled.
Or the inverse, if no clients use DoT, then do not enable the feature.
But please at least get rid of the first word "only".
When that was added the feature was much more experimental than it is these days and it was warranted. Enabling it had several negative side effects at the time, but it doesn't have as many now.
It's still best not to enable it if it's not needed, however, the wording may not need to be quite so strong. That document is still primarily for outbound queries so it's also worded that way to discourage people from enabling it thinking it has any bearing on forwarded queries.
I just pushed a change that reworded things slightly, which should hopefully strike a happy medium.
For 2) I don't feel so strongly about this one, but I'll note the article says further up "Pick a DNS over TLS upstream provider, such as a private upstream DNS server or a public service like Cloudflare, Quad9, or Google public DNS." Why call out those specific companies? Surely "the end user would be the most appropriate place of responsibility for verifying whether their specific upstream provider supports DoT"?
I don't think we should be listing clients since the list will always be out of date and it's a lot of tech debt for us to research and maintain that list. Upstream providers are different, there are only a handful of major public providers and that list doesn't change much.
For 3 & 4) thanks for fixing them. That gitlab.netgate.com link does not work though, so I can't review what you did. Is your gitlab down currently?
That is a private dev server that only Netgate employees can reach. Ultimately, those changes weren't merged, though.
For 3, I've just pushed a change that added TCP there.
For 4, I didn't change anything since the bug that caused those issues was solved in the meantime.
Updated by Sean McBride over 1 year ago
Thank for these updates Jim!
Or the inverse, if no clients use DoT, then do not enable the feature.
I suspect we're past the point where a network is more likely to have some clients that support DoT than no clients that support DoT. Any Apple OS post-2020. Android post-2018-ish. I'd wager most homes/offices have at least one such device on the LAN, don't you think?
It's still best not to enable it if it's not needed
Hmmm, when is/isn't it "needed"? Isn't it better to have secure defaults and enable encryption support by default?
Updated by Jim Pingle over 1 year ago
We have no way of knowing what kind of clients are on a network. Not all of them have traditional client devices like cell phones, tablets, etc. They may be locked down corporate systems with those features disabled. Thus, we have to err on the side of not making that assumption.
It's always a balance. Encryption is good but It's better to not increase your potential attack surface, plus local encryption of DNS queries on your own private L2 is not as strict a necessity as it is for traffic going to a DNS server across the Internet. It's still best to leave that up to the user to decide.
Updated by Sean McBride over 1 year ago
They may be locked down corporate systems...
I strive for something of the sort myself. :) We are close to being able to run with only DoT and no old unencrypted DNS. It would be nice to be able to turn off old DNS. I thought I filed a feature request for that, but can't find it now, do you know if there is such a ticket? If not I'll create one...