[BALUG-Talk] DNS ... CNAME records ... to CNAMES? How long a chain? Loops? ... (those records go bye-bye: 2022-11-12T09:52:00Z)

[Michael Paoli]

On 2022-10-13 00:48, Rick Moen wrote:
> Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
> 
>> DNS ... CNAME records ... to CNAMES?  How long a chain?  Loops? ...
> 
> Or:  Just don't.

Yup, that's generally best approach - at least as feasible.

I tend to, e.g. see
o a CNAME record and think, uhm, yeah, not optimal - at least generally,
   and certainly never optimal for performance.
o a CNAME to a CNAME ... will typically elicit a groan.
o a CNAME to a CNAME to a CNAME ... in production, generally a
   WTF, a double take, a double check, a shaking of the head and
   quite the look of disapproval.
o etc.
o And ... possibly excepting if it's merely for temporary test /
   / demonstration / educational purposes ... and has really or
   essentially no production impacts.  So, yeah, those temporary
   ones I dropped in ... those fit that category.

And yes, temporary, they do go away soon(ish):
# at -l | grep '^71'; at -c 71 | sed -ne "/^echo 
'/{s/$/\\n.../p};/^send'/,\$p"
71      Sat Nov 12 09:52:00 2022 a root
echo 'update del cc-0-tmp.balug.org. 300 IN CNAME www.balug.org.
...
send' |
nspdate -l
:

#

> Over a very large number of years of doing authoritive DNS, including
> for some large Internet concerns, I eventually came up with a 
> guideline:
> Use a CNAME _only_ when an A (and/or AAAA) record cannot do the job --
> and that basically means a cross-domain name reference.
> 
> All other uses of CNAME create risk of errors, one or more of:

Yes, many things that can go wrong - not to mention always sub-optimal
performance (at the very least, additional data getting dragged along,
and that's "best" case).

And all kinds of nastiness can happen if NS and CNAME records interact,
again, yeah, just don't.

> And, believe me, you really need to learn to use scripted editing
> to do DNS maintenance, anyway.  It not only prevents most errors,
> but makes any you commit much easier to find.  Also, it makes rollback
> trivial and fast, no matter how many lines are affected.

Absolutely!  E.g. those test CNAME records I have in place ... yeah, 191
such records ... easily and programmatically added.  And likewise they
also go away when their time has come ... and don't even need to 
remember,
as at(1) will be handling that for me.

Sysadmin laziness^UDevOps efficiency - notably automation, is a good 
thing!

> That is true, but dumb -- because a single one-liner with find, exec, 
> and
> sed can change n lines citing an IP across a group of include files
> exactly as easily as it can one.

Yes, very much so ... and there are many other possible approaches
that can similarly update all the relevant, quickly, easily, and
with negligible probability of introducing errors.

> Let's see, do I follow my own rule?
> 
> :r! grep CNAME /etc/bind/linuxmafia.com.zone
> [censored]  	IN	CNAME	gv-[censored].dv.googlehosted.com.
> 
> Yep.  That's the a record you can voluntarily add to your domain
> if you want to use some of Google's services and let Google
> verify that the domain is yours, like Google's webmaster tools.

Hmmm, I thought they offered some other record type(s) (TXT?) ...
but I haven't looked at that in a while.  Yeah, peeking, have some
older TXT records in balug.org. domain for same or similar with
Google ... though I'm not 100% sure they're still fully functional.
And they may not cover all the current relevant.

> Everything else in linuxmafia.com that _most_ people would use CNAMEs
> for, I use A records -- because that works and makes the possibility of
> whole classes of problem go away.

And, checking for all CNAME records across all the LUG and related 
domains
that, at least I cover the primary master for:
balug.org.
e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa.
sf-lug.org.
sf-lug.com.
sflug.org.
sflug.com.
sflug.net.
sf-lug.net.
berkeleylug.com.
if I exclude the 191 test CNAME records (easy to
do since I did a very nice regular naming convention on
them), after removing those, total count of CNAME records
remaining across all those domains is:
0
Yep, one big fat goose egg.  :-)
So ... around
2022-11-12T09:52:00Z ... well plus TTL of 300s, so:
2022-11-12T09:57:00Z - I'm expecting that total
all inclusive CNAME count (unless something else
gets added before then) to again be back to
lovely zero ... the origin from which we all count.  ;-)