I’ve written down a new rule (no name, sorry) that I’ll be repeating to myself
and those around me. “If you can replace ‘DNS’ with ‘key value store mapping
a name to an ip’ and it still makes sense, it was not, in fact, DNS.” Feel
free to repeat it along with me.
Sure, the “It’s always DNS” meme is funny the first few hundred times you see
it – but what’s less funny is when critical thinking ends because a DNS query
is involved. DNS failures are often the first observable problem because
it’s one of the first things that needs to be done. DNS is fairly complicated,
implementation-dependent, and at times – frustrating to debug – but it is not
the operational hazard it’s made out to be. It’s at best a shallow take, and at
worst actively holding teams back from understanding their true operational
risks.
IP connectivity failures between a host and the rest of the network is not a
reason to blame DNS. This would happen no matter how you distribute the updated
name to IP mappings. Wiping out
all the records during the course of operations due to an automation bug
is not a reason to blame DNS. This, too, would happen no matter how you
distribute the name to IP mappings. Something made the choice to delete all the
mappings, and it did what you asked it to do
There’s plenty of annoying DNS specific sharp edges to blame when things do
go wrong (like 8.8.8.8 and 1.1.1.1 disagreeing about resolving a domain
because of DNSSEC, or since we’re on the topic, a
DNSSEC rollout bricking prod for hours)
for us to be cracking jokes anytime a program makes a DNS request.
We can do better.

Ver todos los episodios