This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

co-location changes

co-location changes
by on (#237864)
Good day everyone,
I just wanted to give everyone the heads up that there will be some co-location changes coming up so there will be some downtime. I am not sure exactly when the changes will happen yet but I will try and keep everyone updated.
Re: co-location changes
by on (#237977)
There aren't any terrible questions here right? This is a bit late, but... what is co-location? Did whatever it is go ok? :)
Re: co-location changes
by on (#237978)
Co-location is where a datacenter provider allows you to rent/lease space in their datacenter, permitting you to place physical rack-mounted servers there, and you pay for the physical space, networking/bandwidth, electricity, etc..

As for if the maintenance is done: I think so.

The sites (forum, wiki, etc.) were down for about ~2-3 days, but that number might be inaccurate because of HTTP caching. During the downtime, there was a Dreamhost(?) web-based error message stating that the site was unavailable or something like that. I don't have a screenshot.

After some people claimed things were back up/working, and DNS had been updated (I verified this; SOA serial had increased), some people continued to see the error page in question (including me). I had to shift-reload all my pages that I'd try to visit during the maintenance to re-fetch the content/bypass caching. Other people continued to get bad DNS data (old IP addresses), probably due to their ISP not honouring DNS TTL properly). The DNS TTL for is 4 hours. (I don't use my ISP's nameservers, so I'm immune to this type of thing. But the HTTP caching problem I did experience.)

The HTTP caching issue is something that should be kept in mind going forward for site-offline maintenances, assuming Dreamhost(?) is still doing the hosting.
Re: co-location changes
by on (#238069)
DNS TTL 4 hours is a really short amount of time right? Unless you require instantanious access to nesdev, 4 hour buffer cuts down on wear on the nesdev server so that can be really good. :)

Thank you koitsu for answering my question. :)
Re: co-location changes
by on (#238074)
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 You do so at 18:00. It resolves to It would continue resolve to (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 (either the entire domain, or per-record e.g. 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 Dreamhost DNS servers and 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's case, the authoritative nameservers are and (see via WHOIS). However, the authoritative NS records for the domain have a third server listed, Either the authoritative nameservers with the DNS registrar ( 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 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).
Re: co-location changes
by on (#238114)
It's also common for a server operator to publish a zone with reduced TTL on all entries in anticipation of a server move. With TTL in the single digit minutes or shorter, stale cache entries don't cause a problem for quite as long, at least in situations where the ISP's resolver doesn't put a counterproductive floor on TTL.
Re: co-location changes
by on (#238136)
Ah, so the DNS TTL just is a caching of nesdev's ip address. Makes sense now, thanks for the instruction koitsu and tepples. You two have extremely vast brains. :) :shock:
Re: co-location changes
by on (#238142)
If you ever read anything about "propagation" of DNS, it's sort of a half-truth. The term "propagation" sort of implies that updates are pushed, as in SMTP (Internet mail), NNTP (Usenet over Internet), or BGP. But in the case of DNS or anything else that's pull-based, treat "propagation" as a popular term for cache expiry.

Perhaps the reason you see a lot of suboptimality in hobbyist implementation of DNS is that DNS sits at the intersection of Phil Karlton's two hard problems in computer science: cache invalidation and naming things.
Re: co-location changes
by on (#238779)
tepples wrote:
Perhaps the reason you see a lot of suboptimality in hobbyist implementation of DNS is that DNS sits at the intersection of Phil Karlton's two hard problems in computer science: cache invalidation and naming things.
It would be so cool if a free pizza shop would open at that intersection: between the cache invalidation market and the naming things garden. Then when going to name a variable you could grab a free pizza! :D

edit: this isn't an optimal idea bc only a portion of people arriving at tepples' Karlton intersection can eat pizza :(