update README

This commit is contained in:
David Blacka 2023-02-26 10:47:09 -05:00
parent e4fbfc09c5
commit 2e991bdcd7
1 changed files with 11 additions and 10 deletions

View File

@ -8,7 +8,7 @@ This repo and directory consists of the revamped DNS service for zeke.ecotroph.n
## Overview
In the past, we just ran the version of BIND that came with our distribution (at this moment, that is CentOS 7, which translates to bind 9.11.) This system runs a recent version of BIND 9 via a docker image produced by ISC themselves. We are staring with 9.18.
In the past, we just ran the version of BIND that came with our distribution (at this moment, that is CentOS 7, which translates to bind 9.11.) This new configuration runs a recent very version of BIND 9 via a docker image produced by ISC themselves. We are staring with 9.18.12.
This docker image imposes a few requirements:
@ -19,32 +19,33 @@ This docker image imposes a few requirements:
## Source
I have this in a local git repository on zeke, however we can see it (sort of) here: <https://blacka.com/cgi-bin/gitweb.cgi?p=docker_bind.git;a=tree> (athough the viewer here is subject to change, and when that does, the URL will change.)
I have this in a local git repository on zeke, however we can see it (sort of) here: <https://blacka.com/cgit/docker_bind.git/tree/> (athough the viewer here is subject to change, and when that does, the URL will change.)
## Design
We have in this repo:
* named configurations. I've broken this up into sections (options, keys, logging, primary, secondary, etc.), which all just get included in the primary named.conf. It isn't tricky.
* "keys". Well, mostly TSIG keys. Those are are but are encrypted with `git-crypt`. With a key that is ... somewhere.
* "keys". Well, mostly TSIG keys. Those are are but are encrypted with `git-crypt`. With a key that is ... somewhere. I've saved it in my password manager, but it can be extracted from the current checkout in `/etc/bind` with `cd /etc/bind; git-crypt export-key /tmp/docker_bind_crypto.key`.
* zone files. I have all of the zone files we started with, although currently the configuration does not load all of them.
* A script to launch the container
* A script to launch the container (`run_bind_container.sh`).
* A script to use as the internal "command" (`cfg/run.sh`) -- it isn't config, but we need to bind-mount it.
* A helper script to run `rndc` that just runs that inside the container itself (via a docker exec). You would need to be in the `docker` group to run it.
* A helper script to prepare zeke to run this container and properly work, in case we want to do this install again.
* A helper script to run `rndc` that just runs that inside the container itself (via a docker exec). You would need to be in the `docker` group to run it. Another helper script to run `named-checkconf`.
* A helper script to prepare zeke to run this container and properly work, in case we want to do this install again (`setup.sh`).
## Installation
1. Clone this repo to `/etc/bind`
1. Clone this repo to `/etc/bind` (clone in `/etc` -- we want the working copy to *be* `/etc/bind`.)
2. Create a user to match the internal user (uid 104): `useradd -u 104 -g 105 -M --no-log-init bind`
3. Change the ownership of everything under `/etc/bind` to the `bind` user and group: `chown -R 104:105 /etc/bind`.
3. Copy the supplied systemd unit file to /etc/systemd/system, and `systemctl enable docker.bind.service`, then `systemctl start docker.bind.service`.
## Zone Changes
All of our zone files are now in this git repo, so we can just make changes and commit them, assuming you have write access to the local repo, that is. Root certainly does, though. Once you've changed your zone, you *could* bounce the service via systemctl, or we could use `rndc`. I've made a little script that will do this with `docker exec`, `/etc/bind/run_rndc.sh`. Thus:
All of our zone files are now in this git repo, so we can just make changes and commit them, assuming you have write access to the local repo, that is. The `bind` user should be able to do it, though. Once you've changed your zone, you *could* bounce the service via systemctl, or we could use `rndc`. I've made a little script that will do this with `docker exec`, `/etc/bind/run_rndc.sh`. Thus:
```bash
sudo -u bind -s
cd /etc/bind/zones
vi <zonefile> # remember to update the serial
git commit -a <zonefile>
@ -58,8 +59,8 @@ cd ..
More modern BIND releases have changed the configuration for this. Now, *how* your zone is signed is based on a `dnssec-policy` block (I've put those in `cfg/named.dnssec.conf`). Then, in your zone, you add:
```
dnssec-policy "simple_alg15";
dnssec-policy "default_alg13";
inline-signing yes;
```
in your zone block. After restarting/reconfiguring BIND, it will create a <zonefile>.signed and <zonefile>.signed.jnl file, and start serving a DNSSEC signed version of the zone. It will then take care of resigning activities, key rollovers etc. Although the policy I'm starting with has just a single DNSKEY with an unlimited lifetime.
in your zone block. After restarting/reconfiguring BIND, it will create a <zonefile>.signed and <zonefile>.signed.jnl file, and start serving a DNSSEC signed version of the zone. It will then take care of resigning activities, key rollovers etc.