Best secure and privacy options for DNS

Hello Pi-hole community!

In this thread, i would like to discuss and tell me your suggestions about DNS settings.
I apologize in advance if I put you in a perhaps subjective confrontation, but I think we can also analyze the issue with technical features.

What do you think are the best adjustment options for a secure, privacy ( and speed ) as possible DNS server ; ; Which “provider” - upstream DNS server - would you choose and why?

At the moment I choose the Quad9 because I have read the best in security and privacy, even at speeds it seems to be doing pretty well. Am I right or have I been the victim of misleading articles?

You (as I show in the screenshot above) are given three different options for Quad9 servers.

  • Quad9 (filtered, DNSSEC) :
  • Quad9 (unfiltered, no DNSSEC) :
  • Quad9 (filtered + ECS) :

Could you tell me what their differences are?
Finally, the “Use DNSSEC” setting, I personally consider it a very good extra security setting, but what do you think?

Anyway it is, it’s amazing and very important that Pi-hole gives us so many choices.

Thanks in advance for your help, technical details and opinions.
Most of all, thank the Pi-hole team for this amazing project! Keep going! :muscle: :v: :+1:

DNS in its classic form is certainly flawed, as it does not address concerns with regard to security, authenticity, integrity, confidentiality or privacy at all.

I have replied to similar topics on several occasions in the past, so let me also refer you to DNS Encryption and the future of PiHole.

Also linked there, DNS Security: Threat Modeling DNSSEC, DoT, and DoH supplies a thorough overview of the current efforts to accomplish more secure DNS operations.

Yet I strongly doubt there can be such a thing as a single best set of settings for Pi-hole.

I presume everyone will settle for those settings that are optimal for their use case, based on more or less complex personal preferences, be they explicitly known or made unconsciously.

Also, discussions on security and privacy of DNS traffic should take into account supplementary procedures outside of Pi-hole as well (like using unbound or employing DNS-over-TLS etc.) as well as the network environment you are operating from (like home, work, wifi cafe, etc.) and your actual users (like family mebers, kids, visitors, colleagues etc.)

You may come up with different solutions for any one combination of the above (not even weighing in other factors I deliberately fail mention here).

With regards to DNSSEC:

Your preference for DNSSEC is justified, as it is the only standard I am aware of that addresses authenticity and integrity including that of DNS records.
However, it falls short on privacy and confidentiality, as the receiving end (i.e your chosen upstream DNS provider) still has full and unrestricted access to your DNS history.

However, enabling DNSSEC on an RPi may be a frustrating experience, as RPis lack the RTC that is elementary for providing correct time which DNSSEC relies on for working, so I wouldn’t recommend it without reservations.

1 Like

In my opinion the best upstream resolver is one you control. Unbound is such a resolver and takes about 15 minutes to setup. The primary advantage is that no upstream server has your DNS history, and the DNS results are accurate and unfiltered. Unbound also performs the DNSSEC authentication.


Awesome. You’re right I hadn’t thought about how sensitive DNS can be. Thank you very much for your in-depth answer/analysis.
It seems that the DNS service is an issue that remains open and unsafe. As we move on to other areas, we are having problems with this radical issue and seems - unfortunately - we don’t care too much about that. However, I guess it will be difficult to deal with.

But existing options (beyond confidentiality/privacy - where responsibility for who to trust is mine) don’t provide any security, authenticity and integrity?

It would be great if Pi-hole also provided some solutions with some simple settings, however as you mentioned above, in such a difficult problem I do not know if these solutions could be provided after a few “clicks”.

A software like the Pi-hole can’t handle such processes in a home network?

Sorry, but what do you mean with RTC ? Why Raspberry Pi haven’t RTC ?

Really? I didn’t know this very interesting project. Unbound looks really interesting and will definitely help beyond security to speed up responses as data is locally sourced I’m right ?
I see once again that the community has a very nice detailed and simple guide to install and configure this service (which I had not unfortunately noticed until now)

I also see this amazing guide : Configuring DNS-Over-HTTPS on Pi-hole.

@Bucking_Horn this isn’t that a nice solution about that or I am wrong ?

Finally, though I eventually see myself to installing my own DNS server, using unbound, for a regular user, which of the existing built-in options would you recommend or would you trust it?

Thanks a lot for your time, great discussion and sharing your views, experiences and knowledge. :slight_smile:

It comes down to personal choice, influenced by your environment, knowledge and willingness to invest yourself into finding the optimal solution for you.

I’ll try to elaborate on that a bit, answering some of your questions as we go :wink:

Classic DNS does not - full stop (and btw, your are wrong about confidentiality, as you’ll see shortly).
Each available extension does only ever address a subset of these areas.

The most prominent option configurable in Pi-hole is DNSSEC.

DNSSEC provides authenticity (i.e. you are indeed communicating to the resolver you think you talk to) and integrity (i.e. no one has tampered with the DNS records you are receiving) by digitally signing DNS records.

It does nothing for confidentiality (i.e.third parties can directly observe and collect your DNS traffic), and privacy is not possible when it comes to the resolver (as that necessarily has to see your requests, so it indeed comes down to a question of trust).

If it would be sound to enable DNSSEC then, why not just enable it in Pi-hole by default?

Well, for DNSSEC to work as intended, your target DNS resolver has to support it as well. In fact, resolver side support is required for any solution extending classic DNS.

So what if your chosen upstream DNS does not provide it at all, or only with notably increased latency? Would you pick another, possibly less trustworthy provider or stick with it and forego DNSSEC?

Another (if minor) parameter is related to the hardware you are using:
A common time frame on the sender and receiver side is required for DNSSEC, making the lack of a dedicated real time clock (RTC) on an RPi a possible source for failure of DNS resolution (if only intermittently and temporarily, until your RPi successfully resyncs with a time server). Can you live with temporary DNS outages?

Also note that there have been occurences of DNS outages due to expired certificates needed for digital singature (something that can never occur with classic DNS).

If you chose to run unbound, BIND or any other full resolver locally, you won't need DNSSEC enabled in Pi-hole, as the local resolver can already handle that.

It will likely be slower, if measurably only.

And no, data isn’t sourced locally: Initial lookups will take longer due to recursing multiple DNS servers, whereas subsequent queries to the same domain during its TTL will not accrue any network latency.

However, similar is true for Pi-hole, caching successfully resolved domains, without accrueing the initial impact of a full recursion.

That said, I wouldn’t expect a noticable difference in day-to-day usage when visiting my usual websites that I frequent regularly.


Finally, note that DNS-over-HTTPS is is distinctively different from DNS-over-TLS.

So, no.
DNS-over-TLS (aka DoT, also corrected my wrong spelling from TCP to TLS) and DNS-over-HTTPS (DoH) share some goals, but they are not identical.

Though not rejecting it per se, I have several concerns about DoH, e.g. as it is employed at application rather than network level, different client applications may resolve the very same DNS names differently, and it promotes further DNS data concentration at a select few DoH resolvers as Cloudflare.

In fact, the link you provided does exclusively make use of one of their tools.

(In the long run, this concentration could mean that your internet plan will become more expensive, as ISPs lose a source of income - it’s not uncommon for ISPs to monetarise your DNS history)

For an in-depth comparison, let me refer you once again to DNS Security: Threat Modeling DNSSEC, DoT, and DoH

1 Like

Unbound is an existing solution, providing all of the above.

Real Time Clock - this feature is not included on the Pi boards. They get their time signal from internet time servers.

Follow the referenced guide in the Pi-Hole documentation page and you will have suitable settings for unbound.

1 Like

I understood the OPs question to ask for Pi-hole’s existing options.
Sorry if I got that wrong.

It is correct that unbound does offer support in each of those areas, but only if configured accordingly (and if all involved authoritative name servers play along nicely, of course):

  • authenticity and integrity of DNS records is provided if DNSSEC is enabled and configured correctly (default: enabled, requires trust anchor for public keys)
  • privacy is addressed by distributing partitioned queries to name servers if strict QNAME minimization is enabled (default: disabled),
  • security is adressed on various levels by various means (including but not limited to exhaustive code audits, dns-0x20, per-query port randomisation with vearying defaults when applicable),
  • confidentiality can be achieved by enabling DNS-over-TLS (default: disabled)

Note that the docs you linked cover for some important settings, but not for all of the above. Also be aware that the tighter you pull the strings, the more likely an odd authoritative name server might refuse or restrict collaboration.

1 Like

I’ve an issue with NTP time service. By default you sync to a “pool” which is a rather un-managed selection of servers on the internet at large. As NTP is a connection-less udp based protocol, your connection to the external “pool” servers opens inbound udp ports on your firewall. If you monitor your internal network with snort, you will have a slew of alarms for dubious servers appearing on your network.

Because that traffic is udp, there is no certainty that every packet in the stream is simply part of an kosher NTP exchange.

One solution is to limit the servers having access to your network by connecting to specific timeservers rather than via a pool, but that is unpopular with the targeted server, as there is now no distribution of load across a pool.

My solution is to build a local tier 1 time source inside my network, based on a raspberry pi with an attached GPS interface. That uses the PPS marker from the GPS to hold the seconds accurate to nanoseconds. It also has a hardware RTC, so it provides timesync immediately after boot. The master timeserver is a chrony instance that syncs to a selected pair of timeservers on the internet at about ten minute intervals.

Everything inside the network takes it’s time from that source.


1 Like

The Pi-Hole guide for unbound will get DNSSEC configured properly (and there are tests provided to ensure it works).

Qname minimisation enabled is the default for an unbound installation -

Edit - you noted “strict qname minimisation”, which is not enabled by default. As noted in the unbound configuration documents " A lot of domains will not be resolvable when this option in enabled. Only use if you know what you are doing."

Enabling DNS-over-TLS in unbound shifts unbound to forwarding mode, not recursive resolver mode. This may hide the DNS queries from your ISP, but you give a third party DNS server your DNS history. In addition, since you will immediately follow an encrypted DNS query with a clear text request for the IP you just received, there is little (if any) confidentiality gain; the ISP can quickly figure where you are browsing.

1 Like

I was explicitly referring to strict QNAME minimisation, as QNAME minimisation by itself will fall back to providing full names if the name server doesn’t agree with minimum labels, potentially compromising privacy.

Quote from the source you've linked (click for more)

Located directly beneath qname-minimisation:

qname-minimisation-strict: <yes or no>
    QNAME minimisation in strict mode. Do not fall-back  to  sending
    full  QNAME  to potentially broken nameservers. A lot of domains
    will not be resolvable when this option in enabled. Only use  if
    you  know  what you are doing.  This option only has effect when
    qname-minimisation is enabled. Default is off.

(Saw your edit just now - click for more)

Yes, the latter is among the reasons for me to mention:

With regards to DoT:

Yes, DNS-over-TLS will forfeit some of your privacy as well, depending on your chosen DNS provider.

However, encrypting DNS traffic via TLS provides a means to protect you from 3rd party eaves-dropping (and thus, confidentiality) as well as establishing the authenticity of the upstream resolver (and thus, authentictiy as well as integrity, if not at the granularity of DNS records like DNSSEC).

You are right again that an ISP could still monitor your following requests (that might or might not be clear text) for live surveillance (i.e. you are already targeted), but DoT still would prevent your ISP from storing and selling your DNS history indiscriminately. Of course, your ISP could still try and extract a domain contact history by observing actual traffic, but at a considerably higher cost.

So I disagree with dismissing DoT as just a means to hide your DNS requests from your ISP.
To me, preferring DoT over DNS rather compares to using HTTPS over HTTP in many ways.

Note that I am not arguing against using unbound in any way -never !
You are nothing less than right in suggesting to make use of it:
Unbound is a solid solution that offers numerous benefits and goes well together with Pi-hole - a dream team.:slight_smile:

I just want to provide some transparency with regards to the (likewise numerous) choices involved (and generally not limited to Pi-hole or unbound).
Which in turn supports my previous statement:
It comes down to personal choice, influenced by your environment, knowledge and willingness to invest yourself into finding the optimal solution for you. :wink:


I really liked your analysis and how you developed it. You really helped me understand some things better…
I also thank you for the further analysis and explanation of unbound and what it offers, what it does not offer, its disadvantages as well as its advantages. It is important to know “all sides of the coin”.
I didn’t expect that it would bring about a slight delay. I suspected that the opposite would happen.
So, if I build/set up a local DNS server, I won’t get faster DNS responses ?

Since we have clarified other concepts, is “DNS resolver” a “DNS server” or not ?

Also I didn’t know that a

There are certainly no “magic pills” as well as some “(panacea solution)”, and if there is, surely you will not succeed easily. It will take a lot of effort and constant effort.

But since the unbound seems to solve a part of these problems/goals, worth a try. Thank you very much for the configurations that were suggested to be made in order to get the best results as possible.

1 Like

There are multiple choices for a Dns Over Tls forwarder.

Some are easier to set up than others.
I’ve posted some rough instructions on installing stubby somewhere around here.

LMK if interested I can dig them up.

1 Like

The rough instructions start here.

When building fetching the dependencies take note replace libyaml with libyaml-dev