its-network/docs/space/srv-acraze/dns.md

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, 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 or from one of the examples below:

grant <NAME>. name _acme-challenge.<RR>.srv.it-syndikat.org. TXT;

The rule above allows the key 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.