Infrastructure Series -- Recursive DNS and Adblocking DNS over TLS w/NGINX

For now. I do think the uptime will be no different.

Ive ran unbound before on my laptop for a year. Never had issues with DoT to the cloudflare servers.

im 99% sure I will see the same results. Ill let you know if it fails though :wink:

Stability update: (you dont need to care but I thought others might)

No hiccups yet

Now Novasty did point something out. You dont need to pull the root hints folks. The unbound package should update that by default. It doesnt hurt to pull the update manually if you have a regularly timed set of mainteance tasks but either will suffice

You say that, but everyone know that disclaimers get ignored.

1 Like

Sounds like the issue is between the “everyone” and the keyboard :wink:

Everyone should know I google most of this stuff. Im not a SME

If everyone knew how to do that, I wouldn’t have a job.


Updated Configuration:

Ive added optimizations. Auth Zones for the master. Hardened DNSSEC further. See below. Alot of which can be drawn from

[[email protected] unbound]$ sudo cat unbound.conf
## Unbound Configuration for Recursive Resolve
# Author: Eric


    # Initial Configuration and Ports
    logfile: "/var/log/unbound/unbound.log" # Define log location
    verbosity: 5
    interface: ::1 # Define if you want to answer IPv6 requests
    port: 31335 

    # IP4/6 TCP/UDP Configuration
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    do-ip6: yes # Enable but not prefer if 6 is a capability on the network (i.e 6in4)
    prefer-ip6: yes # Only enable if on NATIVE IPV6 Stack
    so-reuseport: yes
    max-udp-size: 3072
    udp-upstream-without-downstream: yes

    # Root Hints
    root-hints: root.hints # Top level root servers file
    harden-short-bufsize: yes
    harden-large-queries: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    harden-below-nxdomain: yes
    harden-referral-path: yes
    harden-algo-downgrade: yes
    trust-anchor-file: trusted-key.key
    use-caps-for-id: no # Set no if you plan to use DNSSEC
    edns-buffer-size: 1472 # Set MTU of network
    hide-identity: yes
    hide-version: yes
    hide-trustanchor: yes
    qname-minimisation: yes
    aggressive-nsec: yes
    unwanted-reply-threshold: 10000
    rrset-roundrobin: yes
    minimal-responses: yes
    module-config: "validator iterator"
    root-key-sentinel: yes
    val-clean-additional: yes
    val-log-level: 2
    trust-anchor-signaling: yes

    prefetch: yes
    cache-min-ttl: 0
    serve-expired: yes
    so-reuseport: yes
    msg-cache-slabs: 8
    rrset-cache-slabs: 8
    infra-cache-slabs: 8
    key-cache-slabs: 8
    outgoing-range: 4096
    msg-cache-size: 256m
    rrset-cache-size: 512m
    num-threads: 4
    so-rcvbuf: 8m
    so-sndbuf: 8m
    # Other parameters
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt # Only necessary for DoT Lookups
    private-address: fd00::/8
    private-address: fe80::/10

  name: "."
    for-downstream: no
    for-upstream: yes
    fallback-enabled: yes
    # Set roots as master servers

    # Enable Remote Control
    control-enable: yes
    # what interfaces are listened to for remote control.
    # port number for remote control operations.
    control-port: 8953
    # unbound server key file.
    server-key-file: "/etc/unbound/unbound_server.key"
    # unbound server certificate file.
    server-cert-file: "/etc/unbound/unbound_server.pem"
    # unbound-control key file.
    control-key-file: "/etc/unbound/unbound_control.key"
    # unbound-control certificate file.
    control-cert-file: "/etc/unbound/unbound_control.pem"
[[email protected] unbound]$ 

@Novasty this configuration is more solid for DoT. Ive found lookups fail less and allowing UDP and lookups served in it helps. Especially on mobile. Which used to drop some of my DoT


Zing! But he’s (PLL) correct to be optimistic. I’ve been running various combinations of Pihole, Unbound & Wireguard (OpenVPN before that) for 3-4 years now, ultimately what OS you’re running underneath all of this is the only real question. Everything from Raspian Lite to Ubuntu Server or pure Debian (both physical and virtual machines, as well as SBCs) has been rock-solid stable in my experience. Granted, i’m running a more standard configuration (without NGINX) but the premise remains. This stuff is dead simple to spin up, my old college roommate is terrified of command line and he didn’t have any issues getting a couple Pi-holes running on a brand new RPi4 in an afternoon. Perhaps not everyone should consider running their own DNS, but most competent human beings with a mild interest in technology DEFINITELY should at least consider it.

Unless you love supporting advertising agencies by providing them unlimited access to your data and privacy.


He runs Arch. I’ve never used it, can’t say much about it.


As novasty pointed out I do run arch and Manjaro arm.

It’s rock solid stable just like anything else. The thing it doesn’t have is a security policy

You have to write one. There’s a lot of none sense out there about unsupported distros etc. Truth is it’s linux and Linux is linux. Pedigreeism about distros is annoying.

The reason I ran it is to always be on the latest upstream and because it was lightweight. That was my reason haha

Unbound has been stupidly stable this entire time. Some pihole issues cropped up and the need for some optimizations but that’s it

1 Like

Now this you can fuck off on until all distros decide to finally agree on a unified filesystem structure. I can’t freely just hop over from RHEL to Deb/buntu without relearning a few things here and there because someone had the bright idea of having a completely different philosophy in user experience.

1 Like

They realistically will never do that Debian has its way in Red hat has its way.

Arch seems to come very close to the Red hat way

Suse follows the red hat way

In a lot of ways Debian and Ubuntu are the special snowflakes. But they are the big globby ones you can’t ignore

I like the file structure of Red hat and because Arch does kind of do a similar structure I’m fine on Arch

Then use what you want? All I’m saying is that pedigreeism in choosing one because we think one is better than the other is false

You weigh the pros and cons of what the distro has. Does it suit the purpose you wanted to It’s not going to be better

Almost all posix tools you’ll use function exactly the same way. And a newer kernel functions pretty much the same way.

your terminal is going to function pretty much the same way we’re talking about file paths here.

And it’s frustrating I know I bitched about it too but it’s just like we got to look it up and then we are okay. Fedora in particular threw me off again but I actually started to like its organization’s game with nginx

1 Like

Manjaro was the closest I ever got to dabbling with Arch-family stuff, on my quest to find the perfect (for me) Linux desktop distro I made a quick detour with Manj ~17 maybe, but my preference remains to stick within Deb family stuff, although I don’t love the pure Debian desktop experience, especially if you have modern hardware. But it’s rock-solid, almost boringly stable. Great for set it and forget it appliances I tend to build and tinker with.

1 Like

Testing complete. No issues to report.

Optimizations have worked and are very nice

Memory usage increased 15% but its well within limitations

Additionally you can change all the servers of your pihole if you want to remove the bigger names and just want to use them.

To do so you edit the dns-servers.conf

In my case I want to leave opennic as a fallback. Preserved the accent mark in Québec :wink: (pour les incultes )

[[email protected] pihole]$ sudo cat dns-servers.conf 
UncensoredDNS (1: AnyCast 2:Unicast | DNSSEC | NOLOGS);;;2001:67c:28a4::;2a01:3a0:53:53::
FreeNom (DNSSEC | Anonymized);;;;
OpenNIC (NS5.CA | Toronto | DNSSEC | NOLOGS);;;2604:a880:cad:d0::685d:e001;
OpenNIC (NS12.CA | Toronto | DNSSEC | NOLOGS);;;2604:a880:cad:d0::d9a:f001;
OpenNIC (NS8.CA | Québec | DNSSEC | NOLOGS);;;2607:5300:203:7f27:5054:ff:fe57:4a07;
OpenNIC (NS4.CA | Québec | DNSSEC | NOLOGS);;;2607:5300:203:439c::102;
OpenNIC (NS4.GA.US | Atlanta | DNSSEC | NOLOGS);;;2001:19f0:5401:2a4a:5400:03ff:fe2b:271f;
OpenNIC (NS4.NJ.US | Piscataway | DNSSEC | NOLOGS);;;2001:470:1f07:ed6::;
OpenNIC (NS6.NY.US | New York City | DNSSEC | NOLOGS);;;2604:a880:0:1010::b:4001;


Easy peazy

1 Like

boringly stable is a meme to me. I like rolling it simplifies my life haha

1 Like


To harden your TLS sessions/sockets with the same level of encryption

you need to add this to your stream{} block configurations

    ssl_dhparam             /etc/letsencrypt/dhparam.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ecdh_curve secp521r1:secp384r1;
    ssl_trusted_certificate         /etc/letsencrypt/live/;

@PhaseLockedLoop still love you for this series. I’ve been reading through and looking things up as needed for my own understanding. Thank you for these again.


why not just add it to the beginning of the block and not have to add it to each config?


Because nginx won’t start

It tells me it doesn’t belong there

1 Like

No problem. I expand notes as I find little tweaks lol

I do go further than others about hardening though