### 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 ========= =============================================== ============== .. _dns_external: 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 :ref:`jhu-upstreams_dns`. Reverse Records --------------- Be sure to cross-reference :ref:`networking-external_allocations`. * Our ``128.220.70/24`` subnet is large enough to admit glue records to our DNS servers. These are maintained by JHU (see :ref:`jhu-upstreams_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 :ref:`jhu-upstreams_dns`). Thankfully, these are changed very rarely. .. _dns_dane: 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.