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. ;-)