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

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

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/20200212153723.10156a5f0zoxtao8%40webmail.rawbw.com.