I manage a web site that used to be hosted on Server A. I gave clients a subdomain url that pointed to this server, e.g. app1.example.com
I have moved my web site to a new server, Server B. I changed the IP address of app1.example.com (via the domain name host company) to point to the new server and this worked ok, for me at least. However, I have one client that is still getting directed to the old server.
When I get the client to ping app1.example.com it is trying to ping the old Server A. When I do a ping I get the correct Server B.
I am assuming that the reason for this is that the client must have the IP address cached somewhere. What do I need to tell the client? Would it be to run ipconfig /fluchdns or is the solution going to be more complicated?
The time taken for the DNS records to update over the internet can be anything upto 48 hours.
How long ago did you make the switch to the new server?
If you need them to be able to access it immediatly ask them to edit there DNS record if it is possible. Else you will just need to wait for the DNS update to go through.
It's most likely not the client's fault. There are a lot of ISPs out there whose DNS server reloading intervals are quite long. It can take more than a day hours until a new name server entry is populated to all DNS servers. If it's very urgent, you could tell your client to add an entry to their hosts file.
Related
I have very little experience in administration, so my question may seem silly. Sorry in advance.
My site uses Geolocation in Route 53. That is, I specify the IP address of the server for each user region. For example, users from Japan log in to server1, users from the US log in to server2, and users from Europe log in to server3.
Everything is fine at the moment, but I'm worried about the risks if something goes wrong with different servers. As far as I know, DNS records are cached from the user. Out of concern about this, I have a few questions:
What happens if server1 or server2 goes down? Will Route 53 forward to server3? Or will it not do this automatically and I need to somehow configure Route 53 additionally?
What happens if the IP address of server1 changes? In DNS, of course, I will specify a new IP for Geolocation with the region Japan, but if DNS is cached, then a user who visited the site a week ago from Japan will not be able to get to the site today. Right? That is, I believe that the old IP address of my server will be saved on his computer (cached), and that is where the request will go from the user's computer. That is, it will not know that the IP address has changed. Do I understand correctly? And if that's the case, how do I fix it?
What happens if server1 or server2 goes down? Will Route 53 forward to server3? Or will it not do this automatically and I need to somehow configure Route 53 additionally?
You need to select a health check. Please read this in detail.
What happens if the IP address of server1 changes? In DNS, of course, I will specify a new IP for Geolocation with the region Japan, but if DNS is cached, then a user who visited the site a week ago from Japan will not be able to get to the site today. Right?
Yes
That is, I believe that the old IP address of my server will be saved on his computer (cached), and that is where the request will go from the user's computer. That is, it will not know that the IP address has changed. Do I understand correctly?
Yes, your understanding is correct. The solution is to set a relatively low TTL.
For example, I've a server hosted at my home with 2 NICs for redundancy obviously.
NIC1 has been assigned with the public IP 103.204.82.22 from ISP1
NIC2 has been assigned with the public IP 144.110.12.64 from ISP2
I can access the server with both IP as usual.
Now, I have a domain acme.com. I've created a subdomain server.acme.com. I want to point server.acme.com to both the IPs so that in case one ISP fails to provide connectivity my server still remains online with the other one.
I've already tried with A and CNAME records. But it isn't working. It's working with A record if I use only one IP for the subdomain.
Can anyone tell me what and how can I point both the IPs to the single subdomain?
Thanks in advance
What you are describing is called DNS round robin, but that won't give you your expected outcome.
Anything you do with DNS if one ISP connection is down, traffic will still go there.
You may have your terminology mixed up a little to start with.
in this case, I suspect you really mean that server.acme.com is a host record, rather than a subdomain. (A subdomain would mean that the server address would be at servername.server.acme.com)
If you create an A record, and put both IP addresses in, and keep the TTL (time to live) short, then when a client wants to contact your machine it will randomly pick one of the addresses. If that address is unavailable, it will move on to the next. If that address stops working, it will keep trying it for the 'TTL' time.
Presuming that the IP addresses don't change, which would be a different problem altogether, then this provide basic load balancing and failover to both connections.
Amazon provide a more advanced type of DNS, that will actively monitor your connections and only provide responses that are live. - https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
I have a more specific DNS situation than it is usually asked, and have extinguished reading resources already. At this point I'm pretty desperate. Here is the scenario
Get a computer with OLD IP (let's call it that) for a new domain. Set up for the first time its own ns1.mydomain and ns2.mydomain successfully. They had propagated and all was fine whether you entered mydomain.com or www.mydomain.com
Fast forward a few months, and have to upgrade to new machine, with NEW IP. Soon, I will no longer have access to OLD IP machine. I make an exact copy (went over it many, many times) of the DNS configuration from the old machine on the new one, replacing OLD IP with NEW IP
Since the old machine is still running, I change its DNS records to point to the new IP instead, because I figured it would help 'transfer the authoritative dns' to the new machine. Of course, I have no real grasp of how the authoritative dns is set, even with all my reading.
What followed is that after a few hours (it has been more than a day already by now), typing mydomain.com points to the new IP, while typing www.mydomain.com will keep pointing to the same old one. On the domain.com.zone file, on both OLD IP and NEW IP computers, I have a record for www IN CNAME domain.com.
Also, going to http://www.intodns.com will say "Looks like the A records (the GLUE) got from the parent zone check are different than the ones got from your nameservers".
Doing a nslookup, will say that the authoritative answers can be found at my nameservers, but they still point to the OLD IP
Finally, still after 24h, if I do a service named stop on the OLD IP computer and go to http://www.internetsupervision.com, it will fail finding the DNS for mydomain.com or www.mydomain.com. Yet, if I turn named service back on, it will find it again immediately.
I believe my lack of understanding of the authoritative DNS is preventing me from making a new IP machine start broadcasting the new DNS records. As I've said, I still have access to the old machine, but only for a few more days.
If anyone has any insight to help me in this case, I appreciate. I really don't know what to do any more and have nobody to turn to. Why is my new, updated DNS IP not propagating properly?
The servers telling the world where to go to find authoritative data for your domain are the servers for the parent domain of your domain. That is, if you want to change the IP addresses of the name servers for mydomain.com, you need to change those addresses both on your own servers and the servers for .com. The latter is typically done via an interface (usually web) provided by the people you pay to get the domain in the first place.
Apologies if this is too basic, but you don't mention changing your delegation anywhere in your question.
Reading a lot about servers, load balancing and similar topics, a question came to mind.
DNS servers are servers which gives you the IP for a given domain name. Is there a "dictator" knowing all the valid DNS servers in the world? If I want to make a DNS server, and someone requests a website it doesn't have. How would it know which other DNS to redirect the request to? What if I tell facebook.com to have a spoof IP, and everyone getting the IP from my DNS server would be communicating with a spoof facebook server? Obviously, this isn't how it works (at least not at a big degree), because then someone would have done it already to attack hundreds of people.
When one registers a domain, one has to specify the name server for that domain. What happens during this process? Is a request sent to this DNS server to notify it there is a new domain to save in the database? If so, how can anyone own the top domains like .com? And why cannot I for example make my own top domain name if I can make my own DNS server?
After looking at nginx as a load balancing system, I'm starting to wonder a bit. Is it so that a request to http://www.google.com/ works like this? The computer asks a DNS server for the IP address for google.com, and then requests it? This will only be one IP, and all requests to Google ends up at this one server? And then this IP will be connected to a nginx server, or a more basic hardware unit to route the request internally to other servers? So all requests go to one server before it redirects the request to a data center?
After looking up google.com, it says the name servers are ns1.google.com etc.. But what is the point of them, if you need a different name server to get to ns1.google.com in the first place?
Obviously what I've written doesn't make sense, because if it were true, the web as a whole would be unusable because of people exploiting the possibilities for malicious causes. And I can't imagine how ONE server could handle ALL the requests thrown at google.com.
I've tried searching Google, but all I get is theoretical explanations that led me to where I am now. It would have been great if someone would point me to some articles that explain this thoroughly, and hopefully a lot of other people will find this question useful.
Anyone can run a DNS server, but the challenge is getting someone to use it. Normally the DNS server IP is provided as a DHCP option or is statically assigned. If you can get someone to use your server, you can return any IP for any hostname, including creating new top-level domains (subject to any filtering at the client, of course. Web browsers might have difficulty with a new TLD, for example). Note that with DNSSEC, this will eventually change, as the name record will be digitally signed and your server won't be able to fake the signature exactly.
DNS servers operate in a tree. When one server receives a request for a domain it does not control, it forwards the request on to another DNS server. The other DNS server may be the one which returns the IP (this is called the authoritative server), or it may return a NS record which points to another server which then must be queried. The DNS root servers provide for resolving TLDs.
A DNS server does not need to always return the same IP for a given name. It may choose to return a different IP based on region, client IP, or even per-request. This is the most typical way to load balance. Multiple DNS servers can also load balance the DNS requests by using anycast routing, where many servers share the same public IP and traffic is routed to them randomly by publishing multiple routes for the same IP.
How can I make that a site automagically show a nice "Currently Offline" page when the server is down (I mean, the full server is down and the request can't reach IIS)
Changing the DNS manually is not an option.
Edit: I'm looking to some kind of DNS trick to redirect to other server in case the main server is down. I can make permanent changes to the DNS, but not manually as the server goes down.
I have used the uptime services at DNSMadeEasy to great success. In effect, they set the DNS TTL to a very low number (5 minutes). They take care of pinging your server.
In the event of outage, DNS queries get directed to the secondary IP. An excellent option for a "warm spare" in small shops with limited DNS requirements. I've used them for 3 years with not a single minute of downtime.
EDIT:
This allows for geographically redundant failover, which the NLB solution proposed does not address. If the network connection is down, both servers in a standard NLB configuration will be unreachable.
Some server needs to dish out the "currently offline page", so if your server is completely down, there will have to be some other server serving the file(s), so either you can set up a cluster of servers (even if just 2) and while the first one is down, the 2nd is configured only to return the "currently offline page". Once the 1st server is back up, you can take down the 2nd safetly (as server 1 will take all the load).
You probably need a second server with 100% uptime and then add some kind of failover load balancer. to it, and if the main server is online redirect to that and if it isn't redirect to itself showing a page saying server is down
I believe that if the server is down, there is nothing you can do.
The request will send up a 404 network error because when the web address is resolved to an IP, the IP that is being requested does not exist (because the server is down). If you can't change the DNS entry, then the client browser will continue to hit xxx.xxx.xxx.xxx and will never get a response.
If the server is up, but the website is down, you have options.
EDIT
Your edit mentions that you can make a permanent change the IP. But you would still need a two server setup in order to achieve what you are talking about. You can direct the DNS to a load balancer which would be able to direct the request to a server that is currently active. However, this still requires 100% uptime for the server that the DNS points to.
No matter what, if the server that the DNS is pointing to (which you must control, in order to redirect the traffic) is down, then all requests will receive a 404 network error.
EDIT Thanks to brian for pointing out my 404 error error.
Seriously, DNS is not the right answer to server load-balancing or fail-over. Too many systems (including stub clients and ISP recursive resolve) will cache records for much longer than the specified TTL.
If both servers are on the same network, use routing protocols to achieve fail-over by having both servers present the same IP address to the network, but where the fail-over server only takes over if it detects that the (supposedly) live server is offline.
If the servers are Unix, this is easily done by running Quagga on each server, and then using OSPF as the local routing protocol. I've personally used this for warm standby servers where the redundant system was actually in another data center, albeit one that was connected via a direct link to the main data center.
Certain DNS providers, such as AWS's Route 53, have a health-check option, which can be used to re-route to a static page. AWS has a how-to guide on setting this up.
I'm thinking if the site is load balanced the load balancer itself would detect that the web servers it's trying to redirect clients to are down, therefore it would send the user to a backup server with a message dictating technical problems.
Other than that.....
The only thing I can think is to control the calling page. Obviously that won't work in all circumstances... but if you know that most of your hits to this server will come from a particular source, then you could add a java script test to the source, and redirect to a "server down" page that is generated on a different server.
But if you are trying to handle all hits, from all sources (some of which you can't control), then I think you are out of luck. As other folks are saying - when a server is down, the browser gets a 404 error when it attempts a connection.
... perhaps there would be a way at a point in between to detect 404 errors being returned by servers and replacing them with a "server is down" web page. You'd need something like an HTML firewall or some other intermediate network gear between the server and the web client.