DNS

Internal DNS

We have a whole lot of subnets available internally, with not quite as many subdomains in use.

Subdomain Network(s) Authority
trinidad cluster physical hardware magellan
os OpenStack-controlled names gomes (nova)
vm administrator-managed VMs magellan
muse the computer history museum magellan

Managing External DNS

DNS setup

DNS primary is typhon; it’s replicated onto chicago, echidna, and blaze (CS’s DNS server) via AXFR. typhon runs knot, and the zone files are in git.

Forward Records

  • jhuacm.org is rented and maintained by us directly via tucows. The account information is of course available in non-public notes.
  • acm.jhu.edu glue is maintained by JHU; see DNS.

Reverse Records

Be sure to cross-reference Allocations.

  • Our 128.220.70/24 subnet is large enough to admit glue records to our DNS servers. These are maintained by JHU (see DNS) and should match the forward records for acm.jhu.edu.
  • CS has delegated 216/29.159.161.10.in-addr.arpa and 176/28.35.220.128.in-addr.arpa for us to manage our own reverse records, as per RFC 2317.
  • Our 128.220.251.32/29 subnet is too small for direct glue for reverse records, so they are managed by JHU for us (see DNS). Thankfully, these are changed very rarely.

DANE Records

SSHFP

for i in /etc/ssh/*key; do ssh-keygen -r `hostname -f` -f $i; done

.../scripts/gen-sshfp-records will output SSHFP records for the host it is run on to stdout, nicely formatted for pasting into our zone files. It only looks at the public key files, so it does not need to be run as root.

TLSA

Apparently only limited tooling support exists, but openssl can be used to create particular kinds of TLSA record (SHA256 of the full cert): openssl x509 -in ${CERT}.crt -outform DER | sha256sum will get you the right thing to in for ... in IN TLSA 3 0 1 ( ... ).

There is also the tlsa program from hash-slinger - more info TODO.

While these records are nice to have, the niceness will increase greatly once we get DNSSEC going.

Git-driven DNS maintainence

Clone the repository with:

git clone root@typhon.acm.jhu.edu:/home/git/dns.git

When you push changes, a hook script will automatically validate the modified zone files (including checking that you didn’t forget to change the zone serial number), rejecting the push if this fails, then apply them to the zone files knot sees and tell knot to reload them. The validation uses dnspython; make sure to install python3-dnspython if typhon ever needs to be rebuilt.

DNSSEC

typhon has a key-signing key (2048-bit RSA) and a zone-signing key (1536-bit RSA, both using SHA256 for the signature hash) for acm.jhu.edu and the 128.220.70.0/24 reverse zone and is configured to auto-sign those zones with them. It also has such a pair of keypairs (256-bit ECDSA) for jhuacm.org. The RRSIGs are included in AXFRs, so the secondaries (including blaze!) happily serve signed results (including signed negative results) to whoever asks with the proper bits set, and continue to serve traditional unsigned results to those who don’t.

(The RFC 2317 classless reverse zones are not signed because until the parents are signed and have trust paths, signing them (even with a trust path through DLV) accomplishes nothing.)

And speaking of negative results, we decided to stick with NSEC for that. So all our DNS records are belong to you, if you really want to see them.

There is not a trust path to us (yet!), so those signatures don’t really accomplish much of anything at the moment. Since jhu.edu (along with 220.128.in-addr.arpa) doesn’t play the DNSSEC game, and we have no idea when (if ever) they will, we got records for acm.jhu.edu and 70.220.128.in-addr.arpa into the ISC DLV registry so that there’s a trust path to us through them, for those who trust them. The password for our DLV account is in non-public notes.

Note that the auto-signing causes the serial number in the SOA record we actually serve for signed zones to be one higher than the serial number in the zone file in git. There is no need to skip these numbers in git when making multiple updates in one day though - knot will do the right thing if you just do what you’ve always done.

There should be (but is not yet) something to regularly roll over the zone-signing keys to fresh ones every so often.

DNSSECifying new zones

Warning

This section is stale now that we are running knot v2; the tool to use now is called keymgr. Someone should update the material at hand.

cd into /etc/knot/keys on typhon and make a key-signing key and initial zone-signing key with:

dnssec-keygen -3 -a ECDSAP256SHA256 -f KSK zone.to.sign.example
dnssec-keygen -3 -a ECDSAP256SHA256 zone.to.sign.example

(Substitute your preferred algorithm for the -a option if you want; the -3 only prevents the use of algorithms incompatible with NSEC3, in case you decide you want to use that or leave the option open for later. If you do something like RSA, use -b to specify the number of bits. We like ECDSA for this purpose mainly for the small and fast signatures.)

Chown the keys to the knot user.

If you want to use NSEC3 instead of NSEC to make zone walking harder, add an NSEC3PARAM record to the zone.

Add dnssec-enable on; to the knot.conf block corresponding to the zone, reload knot, and after a brief moment for knot to make the signatures, the zone is signed.

To get the trust path, a DS record needs to be generated from the public half of the key-signing key. Run dnssec-dsfromkey on the .key file for the key-signing key (if you forget which one is the key-signing key, look for a comment in the public key file saying so). Then get the DS record output by dnssec-dsfromkey into the parent zone, alongside its delegation to us. DS records do not get added to the zone we are serving. If the parent zone lacks a trust path, you can instead get an equivalent DLV record (just replace DS with DLV) into the ISC DLV registry in the interim, though not everyone trusts that, and they only support RSA and DSA keys. (Our practice for zones we are forced to use DLV for is a 2048-bit RSASHA256 KSK and a 1536-bit RSASHA256 ZSK - this size chosen to still provide a nice margin of security while not forcing common queries to use TCP. knot requires both keys to be of the same algorithm; otherwise we’d use ECDSAP256SHA256 for the ZSK.)

Todo

This automation uses ssh keys for now, due to the reverse DNS not yet being correct, and therefore Kerberos not being able to work.

At some point we might start passing the zone files through m4 to allow some programmatic generation and expansion of records. But not yet.