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 
Updated by 
Updated by