[sf-lug] Pros/cons; Any chance of elaboration on this point? Re: Dynamic DNS (DDNS)

[Michael Paoli]

> 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?

o con(s):
   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 ...
o pros/cons:
   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
   zone files.
o pros:
   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.