4 ms·
Could you expand on "It was the opposite of DNS: it was never a problem."? Feel like I'm missing some interesting history here.
by moritonal 3y ago
Could you expand on "It was the opposite of DNS: it was never a problem."? Feel like I'm missing some interesting history here.
- klohto 3y agoisitdns.com
- takeda 3y agoThis is lame, it should say No, as you need DNS to load that page :P
- akvadrako 3y agoIt'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.
- sumtechguy 3y agoIn 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.
- byteknight 3y agoAssuming 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".
- mbreese 3y agoIt’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.
- robertlagrant 3y agoDNS, BGP, or branch prediction. Pick three.
- zimpenfish 3y agoStealing from the greats, "DNS, BGP, off-by-one errors, or branch prediction. Pick three."
- jakopo87 3y agoIt was off-by-one, indeed.
- donbreo 3y agoI 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)
- AlexeyBelov 3y agoThat's an issue with JS and/or client library though.
- stephenr 3y agoPeople who don't understand networking like to blame DNS for every problem they experience I guess?
- Terretta 3y agoMeme this is referencing should be "It's always DNS config."
- jameshart 3y agoMostly. 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’.
- Terretta 3y agoSee, 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