[sf-lug] Pros/cons; Any chance of elaboration on this point? Re: Dynamic DNS (DDNS)
Michael.Paoli at cal.berkeley.edu
Sun Jun 5 10:04:55 PDT 2022
> From: "Ronald Barnes" <ron at ronaldbarnes.ca>
> Subject: Re: [sf-lug] Reminder: TOMORROW!: BALUG: meeting: Tu
> 2022-05-17 Dynamic DNS (DDNS), presented by Michael Paoli; & other
> BALUG News
> Date: Fri, 3 Jun 2022 13:05:14 -0700
> Michael Paoli wrote on 2022-05-16 16:35:
>> Reminder: TOMORROW!: BALUG: meeting: Tu 2022-05-17 Dynamic DNS
>> (DDNS), presented by Michael Paoli; & other BALUG News
> Welp, I'm kicking myself for missing this meeting. Sounds
> fascinating, and Michael's DNS knowledge is formidable.
>> o Pros/cons - why would/wouldn't one want to?
> Any chance of elaboration on this point?
if/when one prefers or "needs"(?) a hand maintained zone file, one
loses that, so, e.g. having one's comments in zone file itself, or
having/wanting/needing some very specific structure or ordering of it
or whatever (other than meeting relevant RFC standards, plus whatever
BIND9 might happen to do in terms of how it constructs/orders it) ...
well, that goes away. In my particular case, what I used to put of
such comments in the zone file itself, I now just put in file of same
name with extension of .notes added on the filename ... just
containing the relevant comments/notes/metadata. Zone serial numbers
... with DDNS, one generally won't want to be using YYYYMMDDnn
anymore - at least with BIND9 ... notably as BIND9 won't
automatically maintain that particular type/convention/style of zone
serial numbers and maintenance thereof - but it will automatically
handle serial number updates - and without error ... just not in that
format that's at least recommended ... but not (at all) required.
So, BIND9, with DDNS can be set to use simple increment on serials
(which then have no particular significance other than their number
relative to earlier), and then update frequency is only limited by
2^31-1 and TTL and zone EXPIRY and the like, or one can use unix time
format (seconds since the epoch), in which case updates are "limited"
to once per second - oh they can be submitted much more frequently
than that, just the actual served up zone data changes will be
limited to one set of whatever queued updates, per second.
It might be feasible to use DDNS to manually (or even via program(s))
muck with zone serial numbers, and in so doing, e.g. effectively
maintain a YYYYMMDDnn format - or mostly that. And ...
Might be a con, or pro, or some of both. Historically more DNS
admins would be (more) used to the procedures of manually editing
zone file, then having BIND9 (or whatever) (re)load that updated
configuration file. Nowadays ... such admins may or may not be as, or
more, familiar with updating via DDNS, e.g. using nsupdate or other
tools that use the RFC protocol to make the DNS updates via DDNS.
And, for any that know neither method, probably simpler and less
hazardous to teach the DDNS methods, rather than the zone file edit
methods ... though there might be much more training/reference
materials and documentation around, on the older method of editing the
Well lends itself to automation and scalability. E.g. both personally
and in work environments I use it as part of infrastructure to
automagically obtain letsencrypt.org certs, including complex
multi-domain SAN certs also including wildcards, via letsencrypt's DNS
validation method. Also, likewise, have some LUG/SIG stuff set up
that, via sudo, relatively easily allows other(s) to make all relevant
permitted changes to a subdomain, but not other changes, in DNS, but
not otherwise muck with data for that zone - that would be very
challenging if not infeasible to implement by restricting editing of a
zone file to only changes to a certain subdomain within and nothing
else. Also gain atomicity and the like, so, e.g., avoid the hazards
of two admins, unbeknownst to each other both trying to update and
manually edit a zone file at the same time, and one inadvertently
clobbering the changes by the other, as, e.g. they both started with
copy of same zone file, each added their different additions, then
wrote it out, and reloaded it, but even if their additions were
non-conflicting, neither added the additions of the other. Also, zone
serial numbers - one of the more common booboos with DNS and manually
editing zone files - not only forgetting, but simple booboo such as a
typo of adding a digit or accidentally having a relatively high order
digit be set too high - can quickly introduce a world of hurt ... or at
"best" often introduce quite a pain on how to get the serial number
back to what is/was desired and in use (e.g. YYYYMMDDnn format). Well,
essentially all those serial issues go away and it's automatically
handled ... and without such booboos.
Anyway, that's most of what I come up with off the top-of-my-head.
> I'm thinking of a pro: ability to "ssh thinkpad" without /etc/hosts
> entries and not needing to remember / statically assign IP addresses?
> Can't think of any cons off the top of my head.
More information about the sf-lug