We're developing a client-server game that communicates with our server in real time. During development we directed the client to the server's IP address directly.
Moving forward to release, we'd like to switch the target server IP to a domain name.
I'm looking for feedback whether we should use a sub-domain within our web-site main domain (say: server.mygame.com), or, setup a different domain for the game server (mygame-server.com).
If there is no difference either way I'd love to get feedback on that as well.
Thanks!
This question might be better asked at serverfault.com because it is not strictly related to programming...
Anyway, providing my opinion on your quesion: I'd go for a subdomain of a new game-related main domain.
Here's why: this should give you the most flexability for future changes, assuming the following thoughts:
A new domain especially for that game allows you to promote game information on the www. subdomain.
The game endpoint sits (for example) at api. which points to a different server than any of the websites (improves stability, allows different software for same ports, e.g. web servers).
You can add round-robin DNS load balancing (or any other load-balancing) later. This might be easier if this can be done on a spearate main domain.
You don't have to mess with the main company DNS entries for any game-related settings, improving the stability of both services (as they are separated).
If you might sell the game one day, and a different domain makes it easier to transfer all services and data.
Using a subdomain makes it easier in general because normally the second-level domains (like the A record for example.com) is handled by the DNS servers at a "lower" level in "DNS authority tree" (e.g. at you DNS provider), so it might be more difficult to add special features like load-balancing there.
So these are only some thoughts. Basically it should not matter which way you set up the DNS entries, but if one of the topics above applies (or otherwise sounds reasonable) then you might choose a subdomain on a new domain ;)
Related
I want to make the move to Webflow for a client project that require a CMS. I would like some more information about the logistics and best practices of adding domains though.
Say for instance I have a client’s home page and a blog hosted on Webflow and this is accessed by their custom domain. what if I still need to host additonal files, and other pages on a traditional hosting platform with cPanel?
Would it be best to point the www.clientwebsite.com to Webfllow and keep the clientwebsite.com pointing at traditional host with a 301 redirect to the www.clientwebsite.com
I could still have pages on the traditional host for example clientwebsite.com/page.html while being able to add additional pages to Webflow e.g. www.clientwebsite.com/page.html
Basically I want to be able to use the same domain name on both Webflow and traditional hosting with cPanel, I just want to know what the best way to do this is, is there a better way to achieve this, is there anything to be careful of/ or would be considered bad practice?
Thanks in advance
Typically, one hostname will resolve to one IP address, so one hosting platform has to be the entry point. If the sites can be logically separated, you should probably just use different hostname (blog.example.com, www.example.com, something.example.com) and point them to different hosting platforms.
If you need to have content from the 2 platforms served under the same hostname, then one platform will be the entry point and there it will have some internal rewrite/proxy rules to fetch and serve content from somewhere else. This is easily doable in all modern webservers (nginx, apache..) but I am not sure your CMS platform will allow it.
This is something where I get confused..
Say I acquired a domain name blabla.ge (ge is for Georgia) and hosting my files with US based hosting company. What are the downsides if any and is there an option to change the DNS server?
Cheers!
Agreed, there is no real downside. The tld is really not that important to basic usage. Yes root servers factor in here but really nothing that will impact your daily activities and you don't really need to worry.
For the nameservers, you can change these to any servers you wish and have access to manage the records. Location isn't important other than basic routing and response time. Nameservers generally should be on diverse networks and diverse locations per Best Practices. I have nameservers available in multiple countries and there's nothing wrong with that. If you are using the nameservers provided by your registrar, you likely have the diversity I mentioned, although they may be located in a single country (which is fine).
I have multiple domains registered with tlds such as .nl, .im, .com.de, etc. Some of these point to US-only nameservers, some use nameservers in multiple countries and a couple use the nameservers provided by my registrar (who I purchased the domain from).
From there, my A records point to servers in diverse locations.. Primarily the US and Netherlands. This set up works great, performance is adequate and there are no major downsides to doing it this way. You can change your nameservers for the .ge domain to use US servers or you can leave them overseas and use A records to point to your server(s) in the US. You can debate which method would be "best" given a situation but neither method is "wrong."
So in short, no major downside to doing this at all. And yes, changing your DNS server (nameserver) is always an option. Hope this helps.
I need to determine whether a domain entered by a user is a standard domain e.g example.co.uk or just the TLD e.g co.uk.
Is there a way I can do this e.g. by querying nameservers using nslookup or dig commands?
Just for background, I'm building a tool which works with subdomains e.g. sub.domain.example.co.uk and need to be able to spilt each part of the subdomain into subdomain, domain and TLD parts.
Thanks,
Tom
The "problem" you are trying to solve isn't even well-defined.
There is no way to get this information from DNS itself. DNS makes no distinction between what you call a subdomain, a domain, and a TLD.
Browser makers and other interested parties have apparently not found any solution to this short of building and maintaining a list manually. And even that's an incomplete solution. For example, I know that in Canada you can register a domain as <your-label>.ca, <your-label>.<province>.ca, or <your-label>.<municipality>.<province>.ca, but the current version of Mozilla's list only accounts for the first two possibilities. (Listing all municipalities would be too burdensome anyway).
More importantly, the boundary between what is a "public" domain and a "private" domain isn't a technical one. You're not supposed to be able to register a domain under ac.jp unless you are a university (or similar) in Japan. You're not supposed to be able to register a domain under u-tokyo.ac.jp unless you are a department inside 東大 (or similar). Those two restrictions aren't fundamentally different on a technical level, yet one of those domains is considered "public" and the other one is not. It's a difference of politics/law.
Furthermore, if the public/private domain distinction is being used for security purposes (as it is used for example in web browsers to disallow supercookies), who says that different departments inside one university don't distrust each other just as much as different universities do? There's a well known piece of advice that applies: you shouldn't attempt to solve a political problem with a technical solution.
I'm developing a new website with membership. Do you think any of these has advantages or disadvantages? I thought today that a mobile version will be available and I was planning m.website.com for that but in "username.website.com" case, this won't work. On the other hand, I think website.com/username is ugly.
I need and also want to know your ideas about this.
Thanks.
From a management standpoint, username.website.com will surely be greater. You have to create a new DNS record for each user. In order to do that programatically, you are going to have to manage your DNS with a service that has a API. I am pretty sure registrars like GoDaddy do not have this. Amazon has something called Route 53 that might?
username.website.com will never work as domain names are propagated via DNS servers and through millions of network devices. Any change to the domain name takes time.
Usually, if you want to handle users you can do something like this: www.website.com/users/bob so mobile version will differ only by m. prefix.
It's a lot harder to make a script that sets up subdomains than it is to make a folder for a user.
If you have a mobile site, you could fix the m.username.domain.com by making it username.domain.com/m, if you really want the subdomain.
My half a cent.
I have seen on the web some domain names having prefix of ww2 or ww3 or so (ww2.somedomain.example, ww3.yourdomain.example). And these happen mostly when traveling from a page to page. What would be the reason of having such subdomains? Is there anything special about them or are they just another sub domain? I mean, are they useful in any particular context?
People running large(-ish) sites used to do this when they needed to break up the load between more than one server. One machine would be called www then the next one would be called www2, etc.
Today, much better load balancing solutions are available that don't require you to expose your internal machine naming conventions to the browser clients.
Technically, the initials before the primary domain name (e.g. the "mail" in mail.yahoo.com) can be best though of as a machine name, identifying the web server/mail server, whatever. They can also identify a group of machines (a web farm).
So the person building up that machine can call it anything they want. The initials www are a (somewhat arbitrary) convention.
Oftentimes, ww{x} is used to indicate a particular server of a set of mirrored servers. If properly configured, I could have www.mydomain.example point to my web site on a load balancer, while I could use ww1, ww2, ww3, etc to access the site guaranteed from a specific LBed server.
I can see 3 possibilities
make the browser load resources more faster. the browser would open a fixed number of connection to same domain not to load the server
they are using more then one server so they can share the load between servers
separate some content to a separate virtual host or server. some kind of organization ...
As various answers have pointed out, modern day load-balancers can balance load without having to resort to using different sub-domains for each machine. However, there is still one benefit of dividing your site into various sub-domains: maximize browser connections.
All browsers limit the number of concurrent connections to a particular host (6 for most modern browsers). If a page contains lots of assets, page-load would be slow as the browser queue those requests because of connection limit. By loading different assets from different subdomain, you get around the connection limit, speeding up page-load.
Typically it's a partitioning strategy. When sites get sufficiently large that they can't run (or run well) on a single server you then have to look at solutions for scaling the application out horizontally (ie more servers) rather than vertically (ie bigger servers).
Some example partitioning strategies are:
Certain users always use certain servers. This can be arbitrary or based on some criteria (user type, geographic location, etc);
When a user gets a session that session is assigned to a particular server (sometimes called "sticky sessions" although this can also be used where such different machines are transparent); and
Certain activities are always on certain machines.
Another common case is organizational reasons. In an extremely large company, www might be for their main marketing website. And, ww2 might be, say, for product documentation pages.
In an ideal world, all departments would share perfectly. In practise, a big company might have their (www) marketing pages managed by an external agency. Their internal (ww2) pages done by their internal team. Often, the marketing agency just doesn't update pages quickly or refuses to run certain stacks, may be too limiting in terms of bureaucratic needs.
The marketing agency may insist on controlling the www and not sharing due to past situations where a company website went down due to internal reasons and yet the agency got blamed, or vice versa.
So, theoretically, there's no need to do this with modern load balancing and such. But, in practise, it can be a lot cheaper, straightforward and allow better business productivity.