• Building and running your own DNS-over-HTTPS Server

    There's been a fair bit of controversy over DNS-over-HTTPS (DoH) vs DNS-over-TLS (DoT), and some of those arguments still rage on.

    But, DoH isn't currently going anywhere, and Firefox has directly implemented support (though it calls them Trusted Recursive Resolvers or TRR for short).

    Although DoH offers some fairly serious advantages when out and about (preventing blocking or tampering of DNS lookups by network operators), when left with default configuration it does currently come with some new privacy concerns of it's own. Do you really want all your DNS queries going via Cloudflare? Do you want them to be able to (roughly) tell when your mobile device is home, and when it's out and about (and potentially, also your employer - if they own the netblock)? The same questions of course go if you use Google's DNS too.

    That, however, is addressable by running your own DNS-over-HTTPS server. This also has advantages if you're trying to do split-horizon DNS on your LAN, so I'll discuss that later too.

    The primary purpose of this documentation is to detail how to set up your own DoH server on Linux. The main block of this documentation is concerned with getting a NGinx fronted DoH server backed by Unbound up and running, but will also discuss the steps needed to add Pi-Hole into the mix.

    Unless otherwise noted, all commands are run as root

  • Configuring Pi-Hole to update blocklists more regularly

    By default Pi-Hole updates it's block lists once a week.

    Broadly speaking, this is fine for blocking Ad domains (although the recent trend towards advertisers generating new domains does undermine that a bit).

    But, if you've added a Phishing block list (as detailed in Building Your Own DNS over HTTPS Server), this is far less optimal - Phishing domains tend to do the majority of their damage during the first 24 hours, so only getting an update into the blocklist (potentially) 7 days later isn't much use.

    In this post we'll walk through the (simple) procedure to have Pi-Hole update the gravity lists more frequently

  • Resolving Queries with Pihole via DNS-over-HTTPS

    Video showing queries being resolved by PiHole via DNS-over-HTTPS (DoH) to a VM running on the internet.

    The DNS server was set up as detailed in MISC-27and Building and running your own DoH Server.

  • Tuning Pi-Hole to cope with huge query rates

    As some may already know, I offer a small public encrypted DNS service at dns.bentasker.co.uk, offering DNS resolution via DNS-over-HTTPS (DoH) and DNS-over-TCP (DoT).

    The setup I use is an evolution of that one I described when I published Building and Running your own DNS-over-HTTPS Server 18 months ago, providing ad and phishing blocking as well as encrypted transport.

    It was never intended that my DNS service take over the world, in fact, on the homepage it says

    A small ad and phishing blocking DNS privacy resolver supporting D-o-H and D-o-T.... This service is, at best, a small hobby project to ensure that there are still some privacy-sensitive DNS services out there.

    Not all nodes in my edge even run the DNS service.

    The service has always seen some use - much more than I really expected - with queries coming in from all over the globe, and query rates are pretty respectable as a result.

    However, recently, query rates changed, and there was such a seismic shift in my daily graphs that the previous "routine" usage started to look like 0:

    Daily query rater graph

    I'm omitting figures and dates out of an abundance of caution, but the lines represent usage across different days (the vertical grey lines each denoting a day)

    You can see that usage increased by several orders of magnitude (the turquoise line is the number of advertising domains blocked, so usually increases roughly proportionately).

    The change in traffic rates triggered a few things

    • Alarms/notifications from my monitoring
    • Notifications from some of my connectivity providers to say they were mitigating an apparent DoS

    This post is about the (very few, actually) minor things I found I needed to do to ensure Pi-Hole could keep up with the new load.