Page 1 of 1

co-location changes

Posted: Wed Apr 24, 2019 3:28 am
by WhoaMan
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

Posted: Sat Apr 27, 2019 10:49 pm
by unregistered
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

Posted: Sun Apr 28, 2019 12:45 am
by koitsu
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 nesdev.com 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 nesdev.com 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 nesdev.com 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

Posted: Mon Apr 29, 2019 7:36 pm
by unregistered
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

Posted: Mon Apr 29, 2019 9:05 pm
by koitsu
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 1.2.3.4. It would continue resolve to 1.2.3.4 (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).

Re: co-location changes

Posted: Tue Apr 30, 2019 4:56 am
by tepples
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

Posted: Tue Apr 30, 2019 12:58 pm
by unregistered
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

Posted: Tue Apr 30, 2019 7:44 pm
by tepples
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

Posted: Mon May 13, 2019 4:22 pm
by unregistered
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 :(

Re: запретное видео

Posted: Wed Jan 13, 2021 8:01 am
by kelvin donna
MOD: edited out a quote of a now-deleted spam post
what?
you're back?
what the flipping kitty crud, getting porked by a anime prostitute, hasn't the Deletion Worked?

Re: запретное видео

Posted: Wed Jan 13, 2021 9:41 am
by Quietust
kelvin donna wrote: Wed Jan 13, 2021 8:01 am
StaceyLaB wrote: Wed Jan 13, 2021 4:22 am Всем привет белокожие друзья, нашла очнь интересный сайт, любителей животных.
А увас есть такие фантазии по поводу вязки с человеком? напиши мне,хочу найти таких же людей чтоб вместе эксперементировать.
Желательно с умелым кобельком. Ятемненькая девушка с афрканскими корнями, сейчас живу в России. Во например
<link removed> Прошу администрацию строго не судить, мы живём один раз и я хочу попробовать: ))
what?
you're back?
what the flipping kitty crud, getting porked by a anime prostitute, hasn't the Deletion Worked?
Please don't respond to spambots - the post has already been reported, so all you're doing is giving the moderators one more post to delete (technically 2 more posts, since they'll have to remove my reply to you as well). Furthermore, by quoting the original post and including its spam URL, you're only helping it to advertise itself.

You probably also shouldn't have actually visited that link, since it's quite likely that it'll try to install malware.

Re: co-location changes

Posted: Wed Jan 13, 2021 11:33 am
by lidnariq
I've had to delete a surprising amount of spam in this thread in particular, so I'm going to lock it.