It is currently Fri Aug 23, 2019 2:12 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: co-location changes
PostPosted: Wed Apr 24, 2019 3:28 am 
Offline

Joined: Sat Oct 02, 2004 12:07 pm
Posts: 164
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


Top
 Profile  
 
 Post subject: Re: co-location changes
PostPosted: Sat Apr 27, 2019 10:49 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1034
Location: cypress, texas
There aren't any terrible questions here right? This is a bit late, but... what is co-location? Did whatever it is go ok? :)


Top
 Profile  
 
 Post subject: Re: co-location changes
PostPosted: Sun Apr 28, 2019 12:45 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
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.


Top
 Profile  
 
 Post subject: Re: co-location changes
PostPosted: Mon Apr 29, 2019 7:36 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject: Re: co-location changes
PostPosted: Mon Apr 29, 2019 9:05 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject: Re: co-location changes
PostPosted: Tue Apr 30, 2019 4:56 am 
Offline

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

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
 Post subject: Re: co-location changes
PostPosted: Tue Apr 30, 2019 12:58 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject: Re: co-location changes
PostPosted: Tue Apr 30, 2019 7:44 pm 
Offline

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

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
 Post subject: Re: co-location changes
PostPosted: Mon May 13, 2019 4:22 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1034
Location: cypress, texas
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 :(


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group