DNS TTL (time-to-live) really has nothing to do with the "availability/wear-and-tear" of the server. It just tells hostname resolution stacks how often to expire their cache for DNS records. A higher (larger) TTL means the cache expires less often, which in turn means "less overall" DNS traffic having to hit the Internet. The downside to a too-large TTL is that in the case you need to change an IP, you have to wait longer for everyone to notice the change.
A DNS TTL of 4 hours would mean: pretend it's your first time resolving http://www.nesdev.com
. You do so at 18:00. It resolves to 22.214.171.124. It would continue resolve to 126.96.36.199 (without having to query anything on the Internet) until 22:00, at which time the cache would expire and you'd have to hit the Internet to find out what its IP was, rinse lather repeat every 4 hours.
This model/approach applies universally to DNS stacks everywhere, which means there's caching (Chrome's DNS resolver) atop caching (Windows' DNS resolver) atop caching (nameservers you're querying per your network configuration, e.g. your router) atop caching (your ISP's nameservers or maybe OpenDNS) atop caching (NS records for the domain) atop caching (root servers for the TLD (.com)), etc... It can go very deep.
Some ISPs decide to ignore TTL and enforce their own, which means the TTL set for nesdev.com (either the entire domain, or per-record e.g. http://www.nesdev.com
) wouldn't apply -- you have no control over this and are subject to your ISP's forced TTL. I've heard Verizon does this, for example.
I've seen TTLs as low as 1 second before (which is a very bad practise, BTW). It's common to see some set at 5, 15, or 30 seconds (very aggressive). For commonplace web hosting, that's way too extreme; 4 hours is perfectly reasonable!
The nesdev server itself does not run/manage/host its own DNS. Rephrased: the nesdev webserver does not run an authoritative DNS server for nesdev.com. Dreamhost DNS servers ns1.dreamhost.com and ns2.dreamhost.com are authoritative. This is public information you can look up using any kind of WHOIS tool for DNS, or by checking the NS records for the domain (these two are not always identical, which is bad!). In fact...
In nesdev.com's case, the authoritative nameservers are ns1.dreamhost.com and ns2.dreamhost.com (see via WHOIS). However, the authoritative NS records for the domain have a third server listed, ns3.dreamhost.com. Either the authoritative nameservers with the DNS registrar (http://www.aplus.net
) need to be updated, or the NS records for the domain need to be updated. (This isn't responsible for the issues I saw, but does need to be fixed/updated by WhoaMan or whoever owns the nesdev.com domain + DNS records at this point. The authoritative list and the NS list should match!)
All the DNS bits described above are separate from HTTP caching, which is an entirely different subject (and certainly the root cause of what I saw/had to do, re: shift-reload).