+++
title = "Security & Infrastructure"
description = "An overview of all the infrastructure and services I host, and the security mindset behind it."
date = 2023-09-14
[taxonomies]
tags=["selfhosting", "nix", "privacy", "security", "networks"]
+++

# Security & Infrastructure

Everything on this domain is [self-hosted][0], from DNS to email and all web
services. I currently manage four servers:
- `amsterdam` and `dublin`: VMs running on a physical server I own and control
the physical security of.
- `berlin`: A Vultr VPS.
- `copenhagen`: A Linode VPS.

`amsterdam` acts as the primary nameserver, controlling DNSSEC signing and is
thus the root of trust for the domain. It also runs the primary mail server and
most web services.

`dublin` acts as a secondary nameserver and (soon) a backup email queue and
backup web server for this static site.

Finally, `berlin` and `copenhagen` act as routers for `amsterdam` and `dublin`
respectively. Each has secondary static IPv4 and IPv6 addresses that are routed
over a tunnel to bypass NAT and hosting restrictions on my physical server.
Additionally, these VPSs also act as secondary nameservers in case my home
network is down.

The goal with all of this is to have some basic redundancy, while keeping
sensitive keys and all personal data safely on my physical server.

## DNSSEC
`amsterdam` holds a [combined signing key][13] for the zone. Dynamic updates 
are allowed using [TSIG][1] keys on `amsterdam` and `dublin` to allow [ACME DNS-01 challenges][2] for issuing TLS certificates.

## TLS/HTTPS
`dublin` and `amsterdam` hold a [Let's Encrypt][3] wildcard TLS certificate
for the domain, which is used to protect web services. The DNS zone contains a
[CAA][4] record specifying that only Let's Encrypt may issue certificates for
the domain, and only using ACME DNS-01 challenges. All TLS-capable services have TLSA records associated with them for [DANE-EE][5] support.
Finally, all web services use [HTTPS][6] records and [HSTS preload][7] headers
to advertise support for HTTPS.

## Email
`amsterdam` holds [DKIM][8] keys for the domain, which is published in DNS
alongside [SPF][9] and [DMARC][10] records together protect against spoofing
the domain. [MTA-STS][11] and DANE-EE are used to advertise TLS support for
incoming mail. Outgoing mail requires that the receiving server support TLS.

## WireGuard
All servers hold [WireGuard][14] keys for their end of the tunnels. The tunnel
being encrypted and authenticated isn't actually important for my purposes. This
could just as easily use another tunneling protocol like [GRE][12], but I find
WireGuard trivial to setup even if it adds some keys to manage.

[0]: https://git.averywinters.org/avery/home
[1]: https://en.wikipedia.org/wiki/TSIG
[2]: https://letsencrypt.org/docs/challenge-types/#dns-01-challenge
[3]: https://letsencrypt.org
[4]: https://letsencrypt.org/docs/caa
[5]: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities
[6]: https://developer.mozilla.org/en-US/docs/Glossary/https_rr
[7]: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
[8]: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail
[9]: https://en.wikipedia.org/wiki/Sender_Policy_Framework
[10]: https://en.wikipedia.org/wiki/DMARC
[11]: https://datatracker.ietf.org/doc/html/rfc8461
[12]: https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation
[13]: https://datatracker.ietf.org/doc/html/rfc6781
[14]: https://www.wireguard.com