hhvn.uk

Saturday 23rd May, 2026

nsd(8) + unbound(8)

Something I have wanted to do for quite some time is to delve a bit deeper into DNS, and set up an authoritative name server.

This allows me to configure all the records for my domain on the VPS itself, instead of relying on my domain provider's nameservers and webapp to set everything.

I began by altering unbound's configuration:

-interface: 0.0.0.0
+interface: 127.0.0.1
+interface: 10.44.0.1
	

so that it only runs on the loopback and wireguard address. This frees up 0.0.0.0 for nsd.

As a result of this I had to modify the resolv.conf on my laptop, as I could no longer use my VPS' public IP as resolver. I added a few public resolvers as backups in order to bootstrap to the point where unbound could be used over wireguard.

Next, I configured nsd(8) to run on the public IP interface. I configured a zone file including the basics, as well as x1.hhvn.uk and phone.hhvn.uk

I will still need to use unbound's views to rewrite the records hhvn.uk within the wireguard network.

I configured x1.hhvn.uk and phone.hhvn.uk within the zone file, but in order to configure the PTR records within nsd(8), I would have to set up stub-zones and then ask unbound to use it, so I may as well keep the PTR records within unbound itself.

In order to use ns.hhvn.uk as the nameserver for hhvn.uk, the .uk zone itself has to contain an A record for it. So I contacted my domain provider to set this record up so I could then set it as my nameserver. Since it's a bank holiday weekend I imagine I'll be waiting til Tuesday for this to happen.

So, the next steps:

• Start configuring a mailserver.
• Configure procmail to sort mail, and install and configure an email client. (I've used neomutt previously, but am considering setting it up using notmuch this time, and then I can use some of those features and in the future potentially switch out to different clients more easily or even write one).
• Work out if I'll be storing mail on the server or downloading it locally. If it's stored on the server I will have to figure out a way to encrypt and decrypt it on demand.
• Set up DKIM certificate generation/storag.
• Set up a DKIM signing/verifying relay.
• Once my DNS is fully set up I can start adding the DKIM and SPF and all other related records.
• Write a script to automatically renew DKIM certificates, and then edit the DKIM relay configuration as well as the zone file and reload associated the servers automatically.
• Set up a crontab task to regularly replace the DKIM certificates.
• Cross my fingers and hope my decent spam score is still around for my domain after it lapsed and I repurchased it.

Something that bothered me about my online presence before was the amount of things I had configured with no plan for automation. I tried to use the same certificates and the like for as long as possible to avoid having to manually intervene, but often ended up having things broken and not realizing for a while until I wondered why I couldn't send email, or until someone complained they couldn't access my website...

I am now starting from the ground up with automation as one of the key priorities.

Hopefully I will be able to trust that I can disappear off the face of the earth for a while and not have to pick up the pieces.

There was also pretty much no note-taking or documentation on how things worked, so I would leave stuff for months and come back and have to figure out how it worked from scratch. Part of the reason why I have been writing this "blog" is that I can look back if I need to figure out what I set up previously. It may also be useful to someone else someday, who knows.

Friday, Mar 22nd 2026

rc(1) shell

Today I thought I would return to rc(1) in order to tidy a few bits up so it can compile on both Linux and OpenBSD.

A few files used WIFSIGNALLED() which is located in sys/wait.h, so I added includes for this.

I had to add some explicit rules in the Makefile that would usually be implicit with GNU make. These were to compile helper binaries that generated some signal and status info.

Quite a few of the readline(3) functions used by rc(1) are from more recent versions of the library than packaged with OpenBSD. Previously I had simply commented these out, but I decided to add a couple of no-op functions, and then use preprocessor checks to include these. Originally I intended to check for __OpenBSD__ being defined, however I tracked down the versions of readline(3) in which the functions were added, and then #if checked against the version to see if these no-ops should be included instead. Should potentially help compatibility with other systems.

Finally, I had an issue where rc(1) seemed to think everything was a directoy when carrying out tab-completions. That was not actually the issue. The issue is that variable which told readline to append a '/' was being set, but never unset. Newer versions appear to automatically reset this value, so rc(1) never bothered resetting it. I added a line to reset the variable and it now completes perfectly!

As a result of the no-ops I added, this "port" (if you will), is currently missing these features:

• The alt+!, alt+/ and alt+$ keybinds. These are essentially tab-completions, but explicity tell rc whether to complete a command, path, or variable explicitly, rather than making rc guess. I've never needed these so I am not too worried.
• Screen resizing for readline. The rl_reset_screen_size() function is not present, so this can not be forced by rc. It is likely however that readline has some sort of provision for performing this function on its own, and that the frequency with which rc executes it is not necessary.
• rc-qouting-syntax-specific completion rules. A hook is included to rewrite completions to follow rc's oddball quotation syntax. This hook did not exist in the OpenBSD readline package.

Thursday, Mar 21st 2026

Today I focused on setting up some DNS services.

Having a personal DNS resolver is useful as it allows me to give all my devices on wireguard hostnames.

I enabled OpenBSD's unbound(8) recursive resolver and configured it as follows:

server:
        interface: 0.0.0.0
        access-control: 0.0.0.0/0 allow
        use-syslog: yes
        verbosity: 1
        edns-buffer-size: 1232
        access-control-view: 10.44.0.0/16 wg
        access-control-view: 127.0.0.0/8 lo
	local-data:	"x1.hhvn.uk A 10.44.0.2"
	local-data-ptr: "10.44.0.2 x1.hhvn.uk"
	local-data:     "phone.hhvn.uk A 10.44.0.3"
	local-data-ptr: "10.44.0.3 phone.hhvn.uk"
view:
	name: wg
	local-data:	"hhvn.uk A 10.44.0.1"
	local-data:	"hhvn.uk MX 10 10.44.0.1"
	local-data-ptr: "10.44.0.1 hhvn.uk"

view:
	name: lo
	local-data:	"hhvn.uk A 127.0.0.1"
	local-data:	"hhvn.uk MX 10 127.0.0.1"
	local-data-ptr: "127.0.0.1 hhvn.uk"
	

This superimposes wireguard addresses for the "pseudohostnames" of x1.hhvn.uk and phone.hhvn.uk, referring to my laptop and phone respectively. As neither of these have a fixed address, and are usually sitting behind NAT, it makes sense to always have their DNS lookup point towards their wireguard addresses.

When the resolver is accessed from the 10.44.0.0/16 subnet, which is configured for use in my wireguard network, it rewrites the records for hhvn.uk itself to its wireguard address, keeping all data on wireguard, rather than on the open net.

However on attempting to access the resolver via anything over than the loopback interface, I got nowhere. This is because unbound runs in a chroot at /var/unbound, and I had tried to configure it at /etc/unbound/unbound.conf (which is where the config file is usually found on Linux systems), when really I should have configured it at /var/unbound/etc/unbound.conf).

0 hydn ~$ host hhvn.uk hhvn.uk
Using domain server:
Name: hhvn.uk
Address: 78.141.194.172#53
Aliases:

hhvn.uk has address 78.141.194.172
0 hydn ~$ host hhvn.uk 10.44.0.1
Using domain server:
Name: 10.44.0.1
Address: 10.44.0.1#53
Aliases:

hhvn.uk has address 10.44.0.1
hhvn.uk mail is handled by 10 10.44.0.1.
	

I then disabled resolvd(8), in order to prevent it from automatically rewriting /etc/resolv.conf, and manually editied resolv.conf to use 127.0.0.1 as its nameserver.

On my laptop I rewrote /etc/resolv.conf to use 10.44.0.1 as the primary nameserver, and 78.141.194.172 (hhvn.uk's IP addr) as the secondary nameserver. This allows wireguard to find hhvn.uk in order to establish a connection with it, and once this has been done it then becomes possible to switch over to using the wireguard address as the main nameserver. I also ran chattr +i /etc/resolv.conf, to set the file as immutable in order to prevent dhclient(1) from trying to rewrite it all the time.

On my phone, I simply configured 10.44.0.1 as the nameserver to use in the wireguard app.

Now all of my devices will preferentially use wireguard when available to communicate to each other, and can refer to eachother with hostnames.

Tuesday, Mar 19th 2026

Today I've done a little bit more configuration and set up of the user environment here on the VPS.

I pulled and compiled my slightly modified version of Byron Rakitzis' rc(1).

This required:

• Installing rsync in order to copy the repo onto it
• Installing git so the Makefile can version the binary correctly
• Installing readline as a dependency
• Commenting out half of the readline functions because the OpenBSD readline package is probably a few decades old
• Modified Makefile to manually add recipes for compiling mksignal and mkstatval helper binaries, as OpenBSD make is missing the shorthand that was used
• Adding <sys/wait.h> to all files using WIFSIGNALED()

And now an hour later, I have built a binary. (Well, I did eat dinner at some point in that hour).

TODO: go back and figure out if I can get an up to date readline library installed, or swap to an alternate library.

I then installed the binary, added rc to /etc/shells, and chsh'd it as my main shell.

Tab completion doesn't work correctly, acting like files are directories, so that will need to be addressed. Probably to do with the readline stuff being commented out I would imagine. I plan to add the necessary #ifdef magic and commit the changes so that it can compile flawlessly on either OpenBSD or linux in the future.

I modified my .rcrc to always attach to, or start a tmux(1) session. I also found a tmux_away.pl script for irssi, which I set up.

I've missed being able to remotely access my laptop, so I thought I'd work on networking everything together:

• Installed termux + ssh on my phone
• Copied my phone's ssh pubkeys to the VPS & my laptop
• Installed wireguard on my phone
• Copied the backed up wireguard config and keypair from the old hhvn.uk server to the VPS
• Converted wg-quick(1) format to the much nicer hostname.if(5) format (each peer is contained in one row)
• Set up a new keypair on my phone, and copied it over by ssh'ing into the VPS
• Set up a Termux:Widget to ssh into either hostname straight from the homescreen

The VPS acts as the central hub, at 10.44.0.1, and then the laptop and phone get 10.44.0.2, and 10.44.0.3 respectively. This allows me to connect from any device to any other via the wireguard interface. Success.

Monday, Mar 18th 2026

I took a bit of a break from the online world.

I allowed my domain to lapse, and various other services to cease existence.

And now, I am back.

All that I have set up for now:

• The hhvn.uk domain name
• A vultr VPS running OpenBSD
• tmux+irssi for IRC
• httpd(8) with an index.html
• TLS for hhvn.uk using acme-client(1)

I am comitted to a much simpler technological presence. Everything got a bit too complicated, a bit too fragile, a bit too fancy, and it tired me out. I got too busy to deal with what I had set up, and I simply could not be bothered to tidy it up and simplify, so here I am. Starting fresh.

Some important things to set up:

• opensmtpd(8) email
• wg(4) wireguard VPN

Some not so important things to set up:

• Fix hirc(1) so it doesn't segfault and can be used as my IRC client
• Figure out slowcgi(8) and set up a pastebin
• Set up git-daemon(1) + stagit(1) front end
• geomyidae(8) gopherhole