• An argument in favour of application level name resolution

    Recently I published some documentation detailing how to build and run your own DNS-over-HTTPS (DoH) server.

    As I mentioned at the beginning of that documentation, there's been a certain amount of controversy about DoH vs DNS over TLS (DoT).

    One thread of that argument is along the lines that name resolution should be handled at the OS level (so that all applications get the same result for a given name - improving troubleshooting - as well as giving some caching benefit, versus applications resolving names themselves).

    Generally I've found that argument fairly persuasive, but also taken the view that DoH being implemented at the application level is the result of a general lack of availability/uptake of DoT at the OS level.

    In other words, whilst it's not ideal for applications to be resolving names themselves, it makes an (arguable flawed) privacy-enhancing solution available now, rather than continuing to wait for an (arguably) better solution to actually get adopted (and ignoring whatever reasons led to that lack of adoption).

    But, I've begun to change my mind on whether applications doing resolution themselves really is a problem, or whether it's actually more beneficial when considered alongside some of the aims of DoH

  • Enabling SRS on a CPanel Server

    The default MTA on a CPanel server (Exim) has supported both the Sender Policy Framework (SPF) and the Sender Rewriting Scheme (SRS) for quite some time. Unfortunately, whilst CPanel provides configuration options allowing you to enable and configure SPF, the same cannot be said for SRS.

    This can cause a major headache if you have set-up mail forwarders on your system. This documentation details how to go about configuring SRS.

  • Is your SPF Record Complete?

    The Sender Policy Framework (SPF) is becoming increasingly important as more and more hosts enable it. Chances are that your domain has a SPF record, but is it complete and correct? If not then your mail is likely to end up in the recipients spam folder, or worse bounce completely.

  • PGP Encrypted Text Chat Via DNS

    In a recent post, I alluded to having given a little bit of thought to ways in which clandestine communications could be achieved.

    Having given a little more thought to the idea, I was unable to resist the temptation to build a small proof of concept - if only to see whether there were any obstacles that I hadn't considered.

    This post is the documentation for DNSChat - a small proof of concept enabling PGP encrypted text chat using DNS Queries as a transport mechanism

  • Unbound: Adding Custom DNS Records

    When I wrote my post on configuring DNS, DHCP and NTP on a Raspberry Pi, I forgot to include information on how to add your own DNS records to Unbound (straight forward as it is). So in this post, I'll give a very brief overview.

    All changes should be made in an unbound configuration file (probably /etc/unbound/unbound.conf, though you could also put them into a file in local.d, depending on your distribution - see below)

  • Usurping the BTHomeHub with a Raspberry Pi: Part 2 - DNS, DHCP and NTP

    In Part One, we configured our RaspberryPi to act as a Wireless access point and bridged the wireless and wired interfaces so that WLAN client's were easily accessible from the LAN.

    As part of that setup, we configured a DHCP server, however we haven't yet made it the DHCP server for the LAN - our tired old BTHomeHub is still the authoritative server for the network.

    In this part, we'll be reconfiguring our DHCP server so that it takes responsibility for the entire LAN, configuring DNS services, and making our Pi the LANs central NTP (Network Time Protocol) Server

    Step by step, we'll be configuring our Raspberry Pi to take over nearly all of the duties performed by the BTHomeHub.