Hi all.
I'm the Executive Director of Quad9, as well as an enthusiastic pfSense user for many years.
Using DNS-over-TLS is a good idea, in my book. Encryption of DNS data from your severs to the Quad9 arrays is useful, since your queries then get multiplexed into the query stream with many other users, making it very difficult to determine what your query was. The comment about ENSI above is true but I think insufficient as a reason not to use DNS-over-TLS. Just because some other protocol (HTTPS) is not fully privacy-shrouded doesn't mean you shouldn't try to encrypt everything you can. Despite efforts, the Internet is not all HTTP(s). ☺
Quad9 operates an anycast array. There are multiple resolvers located in each POP. You'll probably fairly consistently be sent to a specific POP, but each session/query may reach a different resolver within that rack. Even if you reach different resolvers within a POP, this should not make a huge amount of difference - your local version of unbound should be doing the heavy lifting on caching, so once you get an answer, you should never ask Quad9 for it again until the TTL expires. Pro tip: if you want to know what city your queries are hitting, try "dig @9.9.9.9 CH TXT id.server" and you'll be handed back the exact name of the server to which that query was delivered. Contained in there is the airport code and optional number of the POP to which you're being delivered. If the location is far away from you, send mail to our support desk (support@quad9.net) and we can give you the name of the closest location. We can get you instructions on how to encourage your ISP to route you in a better way.
Unbound has some TLS problems that are being worked on. Currently, Unbound only sends a single DNS request over a TLS socket connection. As you may expect, this is quite inefficient. There's an open bug on this - comments are welcome. https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4089 I hope to see this fixed soon, and then moved into pfSense. This means (sadly) that Unbound with TLS is quite a bit slower than using UDP unencrypted at the moment. This may not even be notice-able to you; personal preference will dictate what you choose.
Even when this gets repaired, there is a maximum absolute session duration for a socket that will be encountered, and a maximum session duration for a socket with no queries. However, this should introduce no noticeable latency (a few ms round-trip divided by many seconds of hold time is very very small.)
I see some of those "tcp error" messages in my logs if I turn up to "3 - debug" but there doesn't seem to be any negative effects visible elsewhere. I'm not sure what that's about, but there aren't any unexpected results or delays that I can see in the DNS lookups. This might be a logging fault? Or not - I'll look more closely at it in a bit, but since there seems to be no observable downside I'd say just keep your logging at a normal level.
If you're using DNS-over-TLS you can disable Experimental Bit 0x20 Support - you don't have to worry about someone re-writing your query in-flight.
JT
