I've been reading up a lot about DNS lately and have even searched on stack overflow for information, but I can't seem to find this. Please correct me if there's mistake along the way.
Assuming that I want to go to example.com. The way I understand how DNS works is that
It looks on the local client machine for a cached record. If the cache has the record, everything's good. If it doesn't, it moves to step 2.
Makes a request for the domain name to DNS resolver provided by Internet Service Provider (ISP).
If DNS resolver has the domain name record cache, the IP Address is returned and all is well. If it doesn't, it moves to step 4.
DNS resolver uses the DNS Root server hints file to request Root Servers to resolve the appropriate nameserver for Top Level Domain (TLD) (ie: .com, .net, .io).
The request then gets passed down to the TLD server, in this case, responsible for .com. TLD servers have records of nameservers that could resolve "example" called authoritative servers.
The authoritative server then has a record of "example" and returns the IP address to the ISP DNS resolver, who caches that record and returns it to the client who will also cache that record.
My question is lets assume I am typing in "example.ca", but the actual name should be example.com/ca since example.ca does not exist, how does DNS figure out that example.com/ca is the correct entry assuming that neither the local machine nor the ISP DNS resolver has this record cached?
There is no black magic, and it does not have anything to do with DNS: there is a webserver running on http(s)://netflix.ca, and all it does is serve a redirect to https://netflix.com/ca
Related
I am having a bit of a head ache trying to setup my own HA solution with docker and nginx in the front acting as a load balancer.
They are actually configured by now. But as a fallback if the main node shuts down, I want to use another one since the nginx configuration for load balancing is replicated.
I thought that if I have two nodes, both set up with PowerDNS (alongside with nginx and docker), and I set those DNS servers to one of my domains, when a node shuts down, since the node is carrying the DNS server, subsequent requests will fetch the info from the other DNS server, in which the A record is configured to point to the local IP (and that way, points to the other load balancer).
Seems like I can't make that work.
Given that I have the following servers:
server_1 IP = 1.1.1.1
server_2 IP = 1.1.2.2
Each of them have a DNS server set up with PowerDNS (and fully functional, according to dig and other tests).
I got my domain DNS servers pointing to them:
ns1.example.com ---> 1.1.1.1
ns2.example.com ---> 1.1.2.2
ns1.example.com DNS server has:
example2.com A 1.1.1.1
ns2.example.com DNS server has:
example2.com A 1.1.2.2
So. Shouldn't example2.com point to 1.1.1.1/1.1.2.2 when both servers are running, but when the first server is not available, point to 1.1.2.2?
Well. When I shut down the first server and try, it gives me the IP of the first server instead of the second.
Even dig example2.com #ns2.example.com is giving me the IP defined in the A record for example2.com in the first DNS server.
Am I wrong, or there's something weird here?
I don't know where you got the idea that name servers are listed in some sort of priority order, but it's just plain wrong. All name servers authoritative for a zone are expected to have exactly the same content. Resolvers chose name servers to ask at random, to spread the load between them. Providing the authoritative servers with differing contents will only give the end users inconsistent results, not anything useful.
Also, you have forgotten that resolvers cache the answers they get. Even if DNS had worked as you thought (which is doesn't), it would have taken a resolver minutes or hours to notice the "failover".
I am a lot confused in this process of how DNS works. Every link is saying different things, which probably will be the same, but I cannot understand.
I'll try to put forward all what I know and have read. Please add on to this and correct wherever things are wrong.
Type www.example.com in your browser's address bar.
The browser sends a request to the system's OS to check in the hosts file.
The OS checks the hosts file if there exists a record having IP of example.com domain.
If the record exists, the IP address is returned to the browser. The browser then sends the request for the webpage directly to the IP address.
If the record in Step 3 doesn't exists, the browser gets a response from OS that the record is not found. The browser then asks the IP from DNS servers.
(Is this correct? Browser gets a negative response and it sends requests to DNS servers or is it OS which directly requests DNS servers for IP once it knows hosts file doesnot contain the required record).
Now, my main doubt. What exactly are DNS servers? Are they what we call name-servers? Where do they reside? Who provides us with these name-servers? Browser sends them request or OS?
This post says DNS servers are configured on our systems and OS sends a request to these servers.
Now, where do DNS resolvers come then. What are they doing. This post says DNS resolvers are computers owned by ISPs which does the translation. Then is the sequence of request like Browser -> Hosts File-> DNS resolvers -> DNS servers ? But who sends request to whom?
Please correct the above. Any help will be appreciated.
One through five in your list are correct. The browser asks your DNS resolver (your ISP's or whatever you put in your network settings). If the resolver doesn't know the answer it starts asking around.
I'll use stackoverflow.com as an example
The resolver asks the root servers and they answer with the TLD servers authoritative for com.
The resolver asks the TLD servers and they answer with the name servers configured for stackoverflow.com at the domain registrar.
The resolver asks the name servers and they respond with the A record(s)
The resolver caches the A record for a given time (either the TTL of the record or it has its own time overwriting the TTL given by the name servers) and when the resolver is asked again it returns what it has in the cache (unless the TTL has expired, then it starts asking again)
To summarize it looks like this:
Browser -> Hosts File -> DNS resolver ->(rq*) Root servers -> TLD servers -> Name servers -> NS records
rq - recursive query
The NS records are asked if you want to open www.stackoverflow.com, they are like name servers (NS actually stands for name server), but for sub domains.
Just to go into more details about DNS Lookup, here is my example:
When you type www.google.com we actually call www.google.com. The . at the end represents the Root of the Internet’s namespace.
Browser checks its own cache and if not found it asks OS for IP.
OS then checks if the IP address is in memory (cache).
If the browser and the operating system(cache) both don’t know the IP address, then the operating system is configured to ask the Resolving Name Server (RNS) for IP addresses it doesn’t know.
RNS is the main workforce for the DNS lookup. It is configured both manually and automatically within your OS.
The OS then queries the RNS for the IP. RNS may or may not have the IP in cache.
The only thing that all the RNS must know is where to find the Root Name Servers, i.e., the . that appears after every url at the end.
The Root Name Servers will reply with where to find the com name servers.
The com name servers are the Top Level Domain (TLD) name servers.
RNS then caches the info that it com from Root Name Servers and goes to TLD servers.
The TLD name servers will reply by saying the location of google.com name servers. The next set of name servers are the Authoritative Name Servers (ANS).
RNS then caches the info that it com from TLD Name Servers and goes to ANS.
ANS will now reply by saying that it knows the IP address of the URL.
RNS will now save the IP address in its cache and then gives the reply to the OS.
The OS then hands over the IP address to the browser.
Then the browser makes a connection the IP address requesting a web page for the Url.
This entire cycle takes a fraction of a sec.
Browser -> OS -> DNS Lookup -> RNS -> Root Name Server -> TLD -> ANS -> RNS -> OS -> Browser
In this moment, I am learning how the DNS and domains resolutions work and I have a question.
Let's take a.test.com for example.
As I understand it, first of all, the intermediary ISP DNS server is called. If it has the domain IP in cache, it returns it. Otherwise, it does consecutively these following tasks :
It calls a root DNS server which returns a com DNS server IP
It calls that top level DNS server which returns the test.com DNS server IP
It calls that DNS server to finally get a.test.com's IP
Is it correct ?
And now what does it happen when we resolve a.b.c.test.com ?
Does it call another DNS server or does the c.test.com's DNS server contain the a.b.c.test.com's IP ?
Thanks
Yes, you are pretty much correct. Nothing different will happen in next steps: c.test.com will respond with a referral to more authoritative server (the one for b.c.test.com), or if itself is authoritative then it will respond with an answer.
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.
The specific query that led me to try and unpick this process was:
Will a DNS lookup for a subdomain, such as assets.example.com, be faster if the parent domain, example.com, has already been resolved?
By my (naive) understanding, the basic process for translating a domain name into an IP address is quite simple. The addresses of the thirteen root servers, who know how to resolve top-level domains like com and net, are hard coded in network hardware. In the case of a lookup for example.com, our local DNS server, probably our router, asks one of these root servers where to find a top-level nameserver for com. It then asks the resultant nameserver if it knows how to resolve example. If it does, we're done, if not, we're passed to another server. Each nameserver in this process may well be caching, so that for a time our local router will now know offhand where to look for com and example, and the com server will know where to look for example.
Still, I don't really get it.
I know there are other intermediate DNS servers, such as those provided by ISPs. At what point are they queried?
If the com TLD nameserver does not know how to resolve example, how does it work out what other nameservers to check? Or would this simply mean that example.com cannot be resolved?
When I register a domain and configure nameservers, am I in effect editing a group of NS records for my subdomain of a particular TLD in the database used by the nameservers for that TLD?
Wikipedia explains that some DNS servers combine caching with a recursive query implementation which allows them to serve cache hits and reliably resolve cache misses. I don't understand how these servers come to be queried, or how (even broadly) the resolving algorithm works.
Looking back at my initial question, I might take a stab at "no", assuming the A records are both on the same nameserver. Is this accurate?
First, the misconceptions:
The root hints (names and IP addresses of the 13 root servers) are hardly ever "hard coded in network hardware". Network hardware such as a router, may sometimes have a built in DNS resolver if it happens to also have a DHCP server, but if it does, it's usually just a forwarding resolver that passes the query along to an upstream nameserver (obtained from an ISP) if it doesn't know the answer.
nameservers provided by ISPs don't usually act as "intermediate DNS servers". Either you use your own nameservers (e.g. corporate nameservers, or you installed BIND on your computer) or you use the ones provided by your ISP. In either case, whichever nameserver you choose will take care of the recursive resolution process from beginning to end. The exception is the aforementioned forwarding nameservers.
If the com TLD nameserver does not know how to resolve example, it does not work out what other nameservers to check. It is itself the nameserver to check. It either knows about example, or example doesn't exist.
The answer to your question is yes. If a nameserver has already resolved example.com (and that result is still valid in its cache), then it will be able to resolve assets.example.com more quickly.
The recursive resolution process is much as you described it: First find out the nameservers for . (the root), then find out the nameservers for com, etc... Only the recursive resolver does not actually ask for the nameservers for . and com and example.com. It actually asks for assets.example.com each time. The root servers won't give it the answer to that question (they don't know anything about assets.example.com) but they can at least offer a referral to the nameservers for com. Similarily, the nameservers for com won't answer the question (they don't know either) but they can offer a referral to the nameservers for example.com. The nameservers for example.com may or may not know the answer to the question depending on whether assets.example.com is delegated further to other nameservers or provisioned in the same zone as example.com. Accordingly, the recursive resolver will receive either a final answer or another referral.