[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNS Dynamic Update: Re: pi.berkeleylug.com.? :-) (cert, ...)

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
send' |
sudo -g bind nsupdate -l -k \
/var/cache/bind/keys/ddns-key.pi.berkeleylug.com

$

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
send' |
sudo -g bind nsupdate -l -k \
/var/cache/bind/keys/ddns-key.pi.berkeleylug.com

$

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

send' |
sudo -g bind nsupdate -l -k \
/var/cache/bind/keys/ddns-key.pi.berkeleylug.com

update failed: REFUSED
$

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.


From: "Michael Paoli" <Michael.Paoli@cal.berkeley.edu>
Subject: DNS Dynamic Update: Re: pi.berkeleylug.com.?  :-) (cert, ...)
Date: Wed, 12 Feb 2020 15:37:23 -0800



So ... [*.]pi.berkeleylug.com and DNS Dynamic updates ...

Have basic proof-of-concept operational.
And using, for now, a temporary delegated subdomain:
tmp202002.berkeleylug.com.
The "real deal" would use berkeleylug.com.
Otherwise, relatively similar.
So ... subdomain thereof (pi), and Dynamic Updates to that
(and subdomains thereof), but not other DNS data in the zone.
Essentially implemented.  Little mini-demo below:

$ hostname; id; sudo -l | sed -ne '/^User [^ ]* may run/,$p'
balug-sf-lug-v2.balug.org
uid=25322(test) gid=25322(test) groups=25322(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 
$

So, on the DNS master (host balug-sf-lug-v2.balug.org, this is the
balug Virtual Machine) that also hosts BerkeleyLUG.{com,org}.

Have a test user set up (can likewise delegate to relevant users as
applicable), and has sudo access set up as seen above, notably:
(test : bind) NOPASSWD: /usr/bin/nsupdate -l -k /var/cache/bind/keys/ddns-key.pi.berkeleylug.com 
And if user forgets what commands, easy:
$ sudo -l
And they'll be displayed (handy reminder).
So, with the indicated sudo access, we can see that user test can
run the command as group bind.

Below, we can see the desired records aren't yet present:
$ dig +noall +answer pi.tmp202002.berkeleylug.com. A www.pi.tmp202002.berkeleylug.com. A 
$

And then user test uses, in this case echo,
to feed the desired data into sudo which in turn runs the nsupdate
command as group bind:
$ echo -e 'update add pi.tmp202002.berkeleylug.com. 300 A 1.2.3.4\nupdate add www.pi.tmp202002.berkeleylug.com. 300 A 1.2.3.4\nsend' | sudo -g bind nsupdate -l -k /var/cache/bind/keys/ddns-key.pi.berkeleylug.com 
$

We can then see the desired records are present:
$ dig +noall +answer pi.tmp202002.berkeleylug.com. A www.pi.tmp202002.berkeleylug.com. A 
pi.tmp202002.berkeleylug.com. 300 IN    A       1.2.3.4
www.pi.tmp202002.berkeleylug.com. 300 IN A      1.2.3.4
$

Likewise, this user can remove these records (in fact has,
via sudo and that key, permissions to change essentially any DNS
data for pi.tmp202002.berkeleylug.com. and any subdomains thereof):
$ echo -e 'update delete www.pi.tmp202002.berkeleylug.com.\nupdate delete pi.tmp202002.berkeleylug.com.\nsend' | sudo -g bind nsupdate -l -k /var/cache/bind/keys/ddns-key.pi.berkeleylug.com 
$

And after that, we can see that the removal was processed and those
records are gone:
$ dig +noall +answer pi.tmp202002.berkeleylug.com. A www.pi.tmp202002.berkeleylug.com. A 
$

We can also see that our user can't change other data in the zone:
$ echo -e 'update add not-allowed.tmp202002.berkeleylug.com. 300 A 1.2.3.4\nsend' | sudo -g bind nsupdate -l -k /var/cache/bind/keys/ddns-key.pi.berkeleylug.com 
update failed: REFUSED
$


From: "Michael Paoli" <Michael.Paoli@cal.berkeley.edu>
Subject: DNS Dynamic Update: Re: pi.berkeleylug.com.?  :-) (cert, ...)
Date: Mon, 10 Feb 2020 01:05:01 -0800



A little bit closer.

So, thing I'd been thinking about and started (test)
implementation of at BerkeleLUG yesterday (Sunday) ...
with the (proposed) Raspberry Pi, not having static IPv4
address, having a means to updated it ([*.]pi.berkeleylug.com)
in DNS.  Ah, thinks I, ... Dynamic Update.  That and some
suitable sudoers(5) entries, and that should then cover it,
allowing client to update its DNS.

Delegating subdomain (pi.berkeleylug.com) would be more work than
it would be worth (would need to arrange slaves, etc.), so idea
is [*.]pi.berkeleylug.com would be in same zone.
sudoers(5) and/or configuration of Dynamic Updated would be
used to suitably restrict authorized client to only update
[*.]pi.berkeleylug.com DNS data.

But ... for initial testing, easier to start with a
delegated subdomain (easier to test that Dynamics won't
change data where they're not supposed to) ... once all is
well tested and configured and such, can apply that to the
berkeleylug.com zone - with suitable restrictions to
[*.]pi.berkeleylug.com DNS data.

So, for test zone ... tmp202002.berkeleylug.com.
And why such a zone?  Well, won't later conflict with
[*.]pi.berkeleylug.com - even if some remnant data hangs out
for a while (in caches or whatever).  Also, I wanted to
do DNSSEC with it to (as is already the case with
berkeleylug.com) ... got that covered and validated,
and with DNSSEC, best practice with (ZSK) key rotation is
(about) monthly ... already have that covered.  But along with
that, don't want older or possibly conflicting keys hanging
out too long.  Hence, for testing now, separate delegated
sub-domain, that doesn't conflict, and is quite clearly
intended to be temporary.

Oh, and since it's just for proof-of-concept / testing, and
nothin' all that important at the moment ... who needs slaves?
(yeah, I know, RFCs 'n all that, but for a who cares throwaway
anyway ...).
So, DNSSEC ... done: Try this also for a nice view thereof:
https://dnsviz.net/d/tmp202002.berkeleylug.com/dnssec/
And of course:
$ delv tmp202002.berkeleylug.com. SOA +multiline
; fully validated
tmp202002.berkeleylug.com. 291 IN SOA ns0.tmp202002.berkeleylug.com. Michael\.Paoli.cal.berkeley.edu. ( 
                               1581288117 ; serial
                               3600       ; refresh (1 hour)
                               1200       ; retry (20 minutes)
                               604800     ; expire (1 week)
                               180        ; minimum (3 minutes)
                               )
tmp202002.berkeleylug.com. 291 IN RRSIG SOA 8 3 300 (
20200311085137 20200210075137 6543 tmp202002.berkeleylug.com. 
                               Ub0l4cQnPmt47MvguwCW1YHztF6CpWGksWl6MYHiYDgs
                               y3kiyOMAvGd2hmOwQMbU2NndI9DTpfn9iYycxKFZcjP3
                               VTPUD/7iKa7yXXvVq+G81q2YfJx7Aqxe0yczCAG+8G0j
                               0Ui3oYdxb2ZxmqT7b8cVRdDAZ9DwUHkRjgWCvjs= )
$

And ... Dynamic Update, yep, have that implemented too:
$ dig +noall +answer www.tmp202002.berkeleylug.com. A www.tmp202002.berkeleylug.com. AAAA 
www.tmp202002.berkeleylug.com. 300 IN   A       96.86.170.229
www.tmp202002.berkeleylug.com. 300 IN   AAAA    2001:470:1f05:19e::4
# echo -e 'update del www.tmp202002.berkeleylug.com. update add www.tmp202002.berkeleylug.com. 300 A 10.9.8.7update add www.tmp202002.berkeleylug.com. 300 AAAA 2001:470:1f05:19e:babe:face:deaf:beef update add www.tmp202002.berkeleylug.com. 300 AAAA 2001:470:1f05:19e:beef:face:deaf:babe update add www.tmp202002.berkeleylug.com. 300 AAAA 2001:470:1f05:19e:feed:babe:dead:beef 
send' | nsupdate -l
#
$ dig +noall +answer www.tmp202002.berkeleylug.com. A www.tmp202002.berkeleylug. 
com. AAAA
www.tmp202002.berkeleylug.com. 300 IN   A       10.9.8.7
www.tmp202002.berkeleylug.com. 300 IN AAAA 2001:470:1f05:19e:beef:face:deaf:babe www.tmp202002.berkeleylug.com. 300 IN AAAA 2001:470:1f05:19e:feed:babe:dead:beef www.tmp202002.berkeleylug.com. 300 IN AAAA 2001:470:1f05:19e:babe:face:deaf:beef 
$


From: "Michael Paoli" <Michael.Paoli@cal.berkeley.edu>
Subject: pi.berkeleylug.com.?  :-) (cert, ...)
Date: Sat, 01 Feb 2020 09:30:22 -0800



Tom,

Per our earlier communications:

Let me know when you check if you can have open TCP ports
80 & 443 with your ISP on IPv4 (and also, if applicable/available,
IPv6).

We could then:
set up page, likely:
https://berkeleylug.com/pi/
On the BerkeleyLUG web site.
And could then also include link(s) from there to:
http[s]://[www.]pi.berkeleylug.com/
I could also work on setting up dynamic DNS on
berkeleylug.com
and account and suitable access, so you'd be able to change DNS
for [*.]pi.berkeleylug.com.

Oh, and do also have TLS(/"SSL") cert ready for you - if you wish
to use it, and when we have secure means to transfer key (e.g. via
aforementioned above account and ssh/scp/sftp):
          Not Before: Feb  1 15:32:20 2020 GMT
          Not After : May  1 15:32:20 2020 GMT
      Subject: CN = *.pi.berkeleylug.com
*.pi.berkeleylug.com,pi.berkeleylug.com
I use letsencrypt.org, and generally get new certs a bit
more frequently than every 90 days (since they expire after 90 days).
Anyway, got such cert covering the above
(Subject Alternative Name (SAN) & wildcard)
so that would suffice to cover not only
pi.berkeleylug.com, but also any subdomain directly thereunder, e.g.:
www.pi.berkeleylug.com
And you could decide what you'd want the canonical to be
(with or without leading www., and https, or http).
Anyway, not much extra work for me to obtain such cert when I
do all my others (for efficiency, I grab 'em all right around the
same time, so all the expirations are fairly closely aligned, and
then I effectively process 'em all as a (sequential) "batch",
bit more frequent than once every 90 days ... then generally no
other such certs to muck with in the time between).

see also:
http://linuxmafia.com/pipermail/conspire/2020-January/date.html


--
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20200224022632.20422lmbboj24944%40webmail.rawbw.com.