0ne.org does not currently maintain a host with a static IP so cannot be:

So, what can we do?

We do have access to hosts with permanent IP, they just aren't ours. These hosts will have to be our representatives to the net (NS's at the parent zone). We'd like to interact with them as remotely as possible, leaving configuration on hosts we maintain. This leads us to the following configuration.

Subdomains

0ne.org must be responsible for its DNS services. Subdomains (0ne.org's real function) may (and should prefer to) take responsibility (and control) for their own DNS by the following methods (descending degree).

  1. Run their own nameserver
    1. Authoritative by NS records at 0ne.org
    2. Slave 0ne.org off of their nameserver
  2. Rely on 0ne.org's nameserver
    1. Dynamic DNS (nsupdate)
    2. Bother the hostmaster

Of course all these methods rely on 0ne.org's nameservers in some way, so beyond bothering the hostmaster, some amount of dynamic update should be available to all domains regardless of method.

Authentication Options

Controling access to dynamic DNS updates can be done in three ways.

IP Address
Should not be used as IP are easily forged.
TSIG
A viable option, as secure as shared secrets can be. Both the server and client must be in possesion of the secret (symmetric) key, so key management could be a pain.
SIG(0)
A public (asymmetric) key cryptogrophy system (like OpenPGP); the public key is published with DNS and the privite is kept by clients. Clients need not trust another party with the secret and can change their own keys.

So we'll go with SIG(0) authentication for our dynamic updates.

Configuration

When under its control, 0ne.org chooses to use the ISC BIND toolset of which dnssec-keygen, named, and nsupdate mentioned below are a part. These notes were made using version 9.3.2 of BIND.

Keys

dnssec-keygen -a RSAMD5 -b 1024 -n HOST -k -r /dev/urandom 0.0ne.org
-a RSAMD5
Different algorithms are available, but this one is recommended for its implementation support and strength.
-b 1024
Suggested key size in bits, could be from 512 to 4096.
-n HOST
Owner type is appropriate for dyanmic updates.
-k
Forces creation of a KEY resource record (instead of DNSKEY). I don't think should be necessary, but it was.
-r /dev/urandom
The default source of entropy is /dev/random, but when a host is unable to generate entropy, a lower quality but always available source can be had from /dev/urandom .
0.0ne.org
The DNS name of the key.

This will create a pair of keys in two files: a file ending in ".key" containing a zone file snippet for the public key, and one ending in ".private" containing the private key.

K0.0ne.org.+001+KeyID.key
K0.0ne.org.+001+KeyID.private

Zone

Minimally, the zone file must consist of a SOA record and a NS record. Because we will authenticate dynamic updates by SIG(0), we will also include the zone file snippet of the public key for 0.0ne.org generated earlier (K0.0ne.org.+001+KeyID.key).

After this initialization, the zone file will not be primarily under our control; named will occasionally update it with the changes made by dynamic update. As such the file should not reside in /etc as static zone files might, but instead named's working directory, in Debian, /var/cache/bind .

Create the file "db.org.0ne" with the following.

0ne.org.	1d	SOA	0  hostmaster.0 (
				1	; serial
				1m	; refresh
				1m	; retry
				4w	; expire
				1m	; negative
			)
			NS	0
0.0ne.org. IN KEY 512 3 1 KeyData

This defines the zone 0ne.org with a primary nameserver 0.0ne.org and email contact hostmaster@0.0ne.org . This information is updated by zone information with serial numbers greater than 1. Slave (secondary) nameservers should check for changes every 1 minute. If the slave does not get a response, it will try again every 1 minute and continue serving the information it has for 4 weeks. Negative answers expire after 1 minute. 0.0ne.org is an authoritative nameserver for 0ne.org . And finally, a public key for 0.0ne.org .

Nameserver

This named configuration snippet, part of /etc/bind/named.conf.local in Debian, is on 0ne.org's master nameserver.

zone "0ne.org" {
	type	master;
	file	"db.org.0ne";
	update-policy {
		grant 0.0ne.org subdomain   0ne.org ANY;
		grant 1.0ne.org subdomain 1.0ne.org ANY;
		grant 2.0ne.org subdomain 2.0ne.org ANY;
		grant 3.0ne.org subdomain 3.0ne.org ANY;
		grant 4.0ne.org subdomain 4.0ne.org ANY;
	};
};

This configures named as a master nameserver for 0ne.org, storing zone information in "db.org.0ne" relative to named's working directory, allowing dynamic DNS updates of any record type to subdomains of the key name used to authenticate.

rndc reload

rndc is used to control named, locally or remotely. Now that we're done configuring, this command tells named to reload its configuration and zone files.

Making Dynamic Updates

nsupdate can be used to generate dynamic DNS update requests. In our setup, requests are authenticated by SIG(0), using the private key file (thogh the public key file must be present too (bug?)) of a key pair for a (sub)domain as generated earlier. Commands may be entered from a file or interactively. The commands are defined in the nsupdate manpage (which is broken in Debian, see a webpage instead.)

$ nsupdate -k KSubdomain.0ne.org.+001+KeyID.private
>

Modifying Dynamic Zone Files

If you have to make changes to the file of a zone that allows dynamic updates, the following procedure must be followed.

  1. rndc freeze zone

    Disable dynamic updates to the zone. This will sync the zone file and remove its journal (.jnl file).

  2. Edit the zone file.

  3. rndc unfreeze zone

    4. Reload the changed zone and re-enable dynamic updates.

References