Thomas,
Whenever you're ready, we can proceed ... is bit beyond "proof of concept"
for dynamic DNS updates for [[*.]pi.]
berkeleylug.com.
Would just need to coordinate to set up account for you,
and add the relevant sudo bits - then would be all set to go.
Demo bits (presently active on test account):
$ hostname; id -nu; sudo -l | sed -ne '/may run/,$p'
balug-sf-lug-v2.balug.org
test
User test may run the following commands on balug-sf-lug-v2:
(test : bind) NOPASSWD: /usr/bin/nsupdate -l -k
/var/cache/bind/keys/
ddns-key.pi.berkeleylug.com
$
Via that key and sudo access, the account (presently test account),
has access/permissions to do DNS changes to [*.]
pi.berkeleylug.com.
(the whole
berkeleylug.com domain now is set up to be able to use
dynamic DNS updates, there are no delegated subdomains,
pi.berkeleleylug.com. subdomain, and any subdomains thereof,
would remain in the
berkeleylug.com zone ... and hence also
benefit from its existing master and slave DNS servers, etc.)
So, ... example bits. Also, at least from the master, all are allowed
to do AXFR, so anyone can pull the whole DNS zone's data.
First, lets's see what we have for
pi.berkeleylug.com.,
first we peek at SOA and NS records for
berkeleylug.com.:
$ dig +noall +answer +nottl
berkeleylug.com. SOA
berkeleylug.com. NS
berkeleylug.com. IN SOA
ns0.berkeleylug.com.
Michael\.
Paoli.cal.berkeley.edu. 1582499043 10800 3600 3600000 86400
berkeleylug.com. IN NS
ns1.linuxmafia.com.
berkeleylug.com. IN NS
ns1.svlug.org.
berkeleylug.com. IN NS
ns0.berkeleylug.com.
$
We can see from the above, in the SOA, the MNAME is
ns0.berkeleylug.com.,
that would customarily be the DNS origin/master, and in this case is in
fact so, and we can also see it listed among the NS records.
We can also lookup the corresponding IPs, if we need that (may
change, ... but not frequently, and should be able to use the MNAME
name in DNS queries as server):
$ dig +noall +answer +nottl
ns0.berkeleylug.com. A
ns0.berkeleylug.com. AAAA
ns0.berkeleylug.com. IN A 96.86.170.229
ns0.berkeleylug.com. IN AAAA 2001:470:1f05:19e::4
$
And, let's see what (if any)
pi.berkeleylug.com. DNS records exist:
$ dig @
ns0.berkeleylug.com. +noall +answer
berkeleylug.com. AXFR |
> fgrep -i
pi.berkeleylug.com || echo NO MATCHES FOUND
NO MATCHES FOUND
$
Let's add some!
$ echo 'update add
pi.berkeleylug.com. 300 IN A 127.0.0.1
> update add
pi.berkeleylug.com. 300 IN AAAA ::1
> update add
www.pi.berkeleylug.com. 300 IN A 127.0.0.1
> update add
www.pi.berkeleylug.com. 300 IN AAAA ::1
And see what we got!:
$ dig @
ns0.berkeleylug.com. +noall +answer
berkeleylug.com. AXFR |
> fgrep -i
pi.berkeleylug.com.
ns0.berkeleylug.com. 86400 IN NSEC
pi.berkeleylug.com. A
AAAA RRSIG NSEC
pi.berkeleylug.com. 86400 IN RRSIG NSEC 8 3 86400
20200325095614 20200224085614 59679
berkeleylug.com.
UFpBZWUm3bcYmPuwe2NagMVCMCVu9xuq0CT9HPPOlIanpw08Ll5j1Cip
V+3hKcnaYJ1qFMhMaN3YCSAnZxRx2t9VsJj6+RQDsLL/RkzbpViI8UVw
BPm9Lh4LXSmdwtGMoHjNAKzqO9fN7HDF522vuLKNJkwiPC0EW1253mHn 3aU=
pi.berkeleylug.com. 86400 IN NSEC
www.pi.berkeleylug.com. A AAAA RRSIG NSEC
pi.berkeleylug.com. 300 IN RRSIG A 8 3 300
20200325095614 20200224085614 59679
berkeleylug.com.
DaedpxA29N8Q0/EgAGI/coYp9uQntzpw+LT9zQ/fSHODO8X2bC3IOYGI
NaCCB53v5ineCukWIMZ1BeenO7iHUO9DMP6+LZ/1J+noMQvXwrj1/LMQ
ReKGMhRsWgVZ2Zkz07YB31BOUyZw5Xw5+gScPkx6xU6wQ8EdPdQ+g1C+ UOg=
pi.berkeleylug.com. 300 IN RRSIG AAAA 8 3 300
20200325095614 20200224085614 59679
berkeleylug.com.
Y+MHMHYLtVMv63qYkIZSgA+9VO3oBH6ZGtpetkqDcLft164bh+VOdC3q
txA0GgOhsulqLHKIkITsfX5ERYjKQwy62kP5rNjFddDrldcsULGhQqeO
lN5sT+P3WvOrAGOeSo22SxI1IGwSfi6NDftuHbXI/aVGBHDMvkz9wGYC lFM=
pi.berkeleylug.com. 300 IN AAAA ::1
pi.berkeleylug.com. 300 IN A 127.0.0.1
www.pi.berkeleylug.com. 86400 IN RRSIG NSEC 8 4 86400
20200325095614 20200224085614 59679
berkeleylug.com.
JcrifwAnynq3elpDhRmx9QKc/68VECmfeDpCN582dr9HJTLrhrcr0CTh
ZHH7gsnz0Jd0GjosEfdvRS/PG6qrA9DDJQbAJZNVJ0ifebVrQ+o/POpK
j+VtGRw4VY1EQ+1JrEk7QJlA8HK9uFGi95iZ3xQOzicPfuU9NyQm9rBF WG4=
www.pi.berkeleylug.com. 86400 IN NSEC
www.berkeleylug.com. A
AAAA RRSIG NSEC
www.pi.berkeleylug.com. 300 IN RRSIG A 8 4 300
20200325095614 20200224085614 59679
berkeleylug.com.
NjIvNubS7KbdtJVoQb27JQanq3YUV5Fwvevoj2FkTdWhrcvv8+wspiPT
QHAjcf3O3ghDmSEx5OmgVYPE7ocx4VkAZrViWGN1HOcGgzTvEEndMrdb
Xc1j9SnQcFIkYjtDDrTUgTuIiJUknL8j2gjQDAe9tn7KeNBmI+0EwyO8 Zr8=
www.pi.berkeleylug.com. 300 IN RRSIG AAAA 8 4 300
20200325095614 20200224085614 59679
berkeleylug.com.
deQEW1SyOXpGR2i/GJMF5MEBK3haYbq5Qq5QoJbbA5I5/GvlraNMTZHW
e1O4XONQxSKFWRv0cZE3qMCFt0pTImVorU+quViugzgwGGNhFdYTMQNh
df1WAKS6bWHkHKU8KvCFvL+sute/9KUfRWGYdOWc/lWds5L2673psmKu Ay8=
www.pi.berkeleylug.com. 300 IN AAAA ::1
www.pi.berkeleylug.com. 300 IN A 127.0.0.1
$
And, there one can see, the added records (NSEC and RRSIG are
automatically added as part of the configured DNSSEC).
And likewise, if we remove them
$ echo 'update delete
pi.berkeleylug.com. IN A
> update delete
pi.berkeleylug.com. IN AAAA
> update delete
www.pi.berkeleylug.com. IN A
> update delete
www.pi.berkeleylug.com. IN AAAA
We then see that the records are gone:
$ dig @
ns0.berkeleylug.com. +noall +answer
berkeleylug.com. AXFR |
> fgrep -i
pi.berkeleylug.com. || echo NO MATCHES FOUND
NO MATCHES FOUND
$
Including the removal of the related NSEC and RRSIG records that our
DNSSEC configuration had automatically added.
And if we try something else in the zone in DNS:
$ echo 'update add
foobarbaznotallowed.berkeleylug.com. 300 IN A 127.0.0.1
That fails, as it doesn't match what our configuration allows
by use of that key. In relevant part from our configuration:
update-policy {
grant
ddns-key.pi.berkeleylug.com subdomain
pi.berkeleylug.com.;
};
Oh, also, 86400 (from SOA we showed earlier) is the
MINIMUM Negative Cache TTL value for the zone,
it's "global" for the zone, can't set that differently for
Resource Records (RRs) within. So, to avoid long negative caching,
may want to leave at least some record - e.g. a TXT record may suffice,
and leave that, thus response won't be an NXDOMAIN, which may be cached
up to 86400 (seconds - one day)
per MINIMUM Negative Cache TTL value for the zone.