dd9b89a39c
Explain to users how to add their own nsupdate keys, allow the key to do something and how our dnssec is handled. Signed-off-by: Wachtl Enterprises LLC <tyrolyean@escpe.net>
120 lines
4.7 KiB
Markdown
120 lines
4.7 KiB
Markdown
# About
|
|
|
|
`velcro.srv.it-syndikat.org` is the local DNS server. It handles both recursion
|
|
and is a authoritative domain server. Access to recursion is restricted using
|
|
ACLs.
|
|
|
|
# Maintainers
|
|
|
|
Current Maintainers:
|
|
|
|
- tyrolyean: DNS and stuff
|
|
|
|
# Technical
|
|
|
|
## Software
|
|
|
|
The box itself is an ArchLinux installation due to bind receiving a lot of new
|
|
features regarding DoT and DoH lately, which have not been backported to any
|
|
majour distributions as of right now. It acts as recursor for all traffic from
|
|
space subnets as layed out in the [IP-Address Plan](../router.md), and as
|
|
master and dnssec signer for all IT-Syndikat zones.
|
|
|
|
## Zones
|
|
|
|
The server is master for all zones the IT-Syndikat has, and transfers them to
|
|
our secondary and tertiary NS, namely `hannibass` and `srv`. `it-syndikat.org`,
|
|
`it-syndik.at` and `openbdsm.org` are all served from here. Serials for root
|
|
zones are currently in the RFC-recommended date based format, Third level
|
|
domains however, such as `asozial.it-syndikat.org` and `srv.it-syndikat.org` are
|
|
increment based, because they can exceed 99 updates a day, meaning they would
|
|
wander of into the future, making the date confusing instead of helpfull.
|
|
|
|
The `.cuco` TLD for the cunst subnet is also served on here.
|
|
|
|
### Configuration
|
|
|
|
Configuration file is `/etc/named.conf`. It's permissions are supposed to be
|
|
`600`, to protect the tsig-keys stored inside.
|
|
|
|
#### Update records
|
|
|
|
The master zone files are located in `/var/named/zones/`. If you want to edit a
|
|
zone file, first freeze them with `rndc freeze <domain>`, then edit the file,
|
|
and unfreeze with `rndc thaw`. Root zones may be static, meaning there is no
|
|
need to freeze them. rndc will inform you via the
|
|
`rndc: 'freeze' failed: not dynamic` message of this. In that case, you can get
|
|
bind to reload the zone file using the `rndc reload <domain>` command.
|
|
|
|
|
|
#### Add a key for nsupdate
|
|
|
|
You need this if you want to perform letsencrypt dns challenges, or want to
|
|
perform dyndns to an rr.
|
|
|
|
First, generate a key using `tsig-keygen -a hmac-sha512 <NAME>` with NAME
|
|
being, given our usage of this key further on, the non-FQDN name of the machine.
|
|
It does not need to match the record the key is used further on, we set this
|
|
relation further down by hand.
|
|
|
|
Copy the key into your application and into `/etc/named.conf`. Next locate the
|
|
`update-policy` section in your zone. If it doesn't have one, the zone is not
|
|
dynamic. If you add a `update-policy` section, beware that this will alter the
|
|
on-disk zone file and remove all hand formatting of the zone, which will
|
|
afterwards be sorted alphabetically as well.
|
|
|
|
You need to add a new rule to allow your nsupdate, which you need to craft by
|
|
hand using
|
|
[ISC's documentation](https://bind9.readthedocs.io/en/latest/reference.html#dynamic-update-policies)
|
|
or from one of the examples below:
|
|
|
|
```
|
|
grant <NAME>. name _acme-challenge.<RR>.srv.it-syndikat.org. TXT;
|
|
```
|
|
|
|
The rule above allows the key <NAME> to perform a letsencrypt dns-01 challenge
|
|
for `<RR>.srv.it-syndikat.org.` and `*.<RR>.srv.it-syndikat.org`.
|
|
|
|
```
|
|
grant <NAME>. wildcard *.srv.it-syndikat.org. A AAAA DHCID TXT;
|
|
```
|
|
|
|
This is what we use for our dhcp ddns setup. This DDNS key needs to be able to
|
|
add TXT/DHCID records as well, to store information about the record and if it
|
|
belongs to the DHCP server, or has been set manually. Kea uses the DHCID field
|
|
for this, whilest ISC-DHCP uses the TXT record. We allow both, as to not break
|
|
our future probable migration to kea.
|
|
|
|
### Zone transfers
|
|
|
|
Zones are transferred to the slaves over wireguard tunnels, which, as they are
|
|
all dnssec-signed, makes encrypted and further signed domain transfers less of
|
|
an issue. Therefore slave binds only look at the source IP wether an inbound
|
|
notify is valid.
|
|
|
|
### DNSSEC
|
|
|
|
DNSSEC is a mechanism inside the DNS to cryptographically verify responses
|
|
served. It does not encrypt DNS traffic, nor does it anonymize it. DNSSECs only
|
|
purpose is for the recursor to be able to trust the response it gathers. All our
|
|
zones are signed and the KSKs are delegated to us from the TLD NSes.
|
|
|
|
Bind automatically manages DNSSEC keys and key rollovers using it's builtin
|
|
`dnssec-policy`. Our current ed25519 based policy consists of a KSK which never
|
|
expires and delegates the authority to the ZSK, which handles zone signing and
|
|
is replaced every 60 days, which looks something like this:
|
|
|
|
```
|
|
dnssec-policy "its-policy" {
|
|
keys {
|
|
ksk lifetime unlimited algorithm ed25519;
|
|
zsk lifetime P60D algorithm ed25519;
|
|
};
|
|
};
|
|
```
|
|
|
|
A zone is automatically DNSSEC signed, once you set it's `key-directory` and
|
|
`dnssec-policy` fields. Whilest this option is cryptographically secure, some
|
|
recursors do not support ed25519 at this time. All recursors we and our members
|
|
operate do though, which is why we only sign using ed25519, and not any other
|
|
key variant.
|