It’s just a common saying “the problem is always DNS”. When you have a weird networking issue, the problem always seems to be DNS. Either some misconfigured DNS entry or DHCP giving you the wrong server address, etc…

And then the problem is confounded by the fact that, ironically, DNS works so well that we don’t think of it as a primary point of failure. So inevitably, when there is a DNS problem, it’s the last thing we check. This just reinforces the idea that the problem is always DNS… because in those long, hard to troubleshoot instances… the problem was DNS.

DNS, BGP, or branch prediction. Pick three.

Stealing from the greats, "DNS, BGP, off-by-one errors, or branch prediction. Pick three."

It was off-by-one, indeed.

I just faced an issue with redis this week. It was causing my Javascript heap memory to go bust. I thought it was a data leak in my code but it turns out the redis client was filling it up and I fixed it by simply adding a static delay every 1 million set operations so that the garbage collector had enough time to do its job. (I was stress testing for a total of 6 million set operations)

That's an issue with JS and/or client library though.

It's weird since DNS is one of the most rock solid systems we have, with redundancy at every level.

1. Clients query a list of servers (IPs) and handle failover when you don't quickly get a reply.

2. Most of those servers at the root and TLD level are actually anycasted from multiple locations globally, so you connect to the closest instance.

3. Those instances are often clusters of physical servers. The big ones have fully redundant networking, so any router or switch failing doesn't take it down. Some run different DNS server software on each physical server, so even software bugs won't take down the whole system.

In my years of doing this sort of thing. I only had it really be DNS once. The issues I usually see blamed on DNS is when DNS is 'abused' to do things like load balancing and the TTL is very small. Then you need goofy things like 'sticky sessions' and what not to work around that.

Assuming you didnt manage connectivity of systems very long or very many. I find it difficult that not being true with you saying it happened "once".

People who don't understand networking like to blame DNS for every problem they experience I guess?

isitdns.com

This is lame, it should say No, as you need DNS to load that page :P

Meme this is referencing should be "It's always DNS config."

Mostly. But it can also be DNS request volume, DNS cache expiry, DNS response times, DNS connection contention, DNS security, DNS error handling, or DNS client configuration.

All variants of ‘DNS is working perfectly, just your expectations of how it will work in your situation are not completely correct’.

See, config. :-)

// wrote what might have been first commercial-use dynamic DNS server for a regional ISP in early 90s, invented an unreasonably effective geo+latency balanced anycast-like DNS for global video delivery network in 00s