Project

General

Profile

Actions

Todo #13456

open

Feedback on pfSense® software Configuration Recipes — Configuring DNS over TLS

Added by Sean McBride 3 months ago. Updated 3 months ago.

Status:
Pull Request Review
Priority:
Normal
Assignee:
-
Category:
DNS
Target version:
-
Start date:
Due date:
% Done:

90%

Estimated time:

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.

Actions #1

Updated by Chris W 3 months 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.

Actions #2

Updated by Chris W 3 months ago

  • % Done changed from 0 to 90
Actions #3

Updated by Chris W 3 months ago

  • Status changed from New to Pull Request Review
Actions #4

Updated by Sean McBride 3 months 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?

Actions

Also available in: Atom PDF