co-location changes

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Locked
WhoaMan
Posts: 167
Joined: Sat Oct 02, 2004 12:07 pm

co-location changes

Post 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.
i dont have much to say
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: co-location changes

Post 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? :)
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: co-location changes

Post 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.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: co-location changes

Post 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. :)
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: co-location changes

Post 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).
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: co-location changes

Post 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.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: co-location changes

Post 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:
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: co-location changes

Post 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.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: co-location changes

Post 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 :(
kelvin donna
Posts: 70
Joined: Sat Feb 01, 2020 5:49 am

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

Post 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?
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

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

Post 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.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: co-location changes

Post by lidnariq »

I've had to delete a surprising amount of spam in this thread in particular, so I'm going to lock it.
Locked