How do browsers choose DNS server to resolve?

Yesterday, 04:13 AM I was thinking that browsers choose DNS server in order of appearance. For example, if NS1.domain.com is responding, the browser will not check NS2.domain.com, but if the first record is failing, the browser will try the next one.

However, DNS management providers now offer DNS at different countries. It seems that choosing DNS is similar to CDN, as the browser will choose the nearest DNS server. For example, they offer

NS1.dnsprovider.com (located in US)
NS2.dnsprovider.com (located in EU)
NS3.dnsprovider.com (located in Asia)

Does really browsers find the nearest DNS server? or as long as the US DNS server (the NS1) is responding, the rest is not considered at all?

Last edited by etrader; Yesterday at 04:19 AM.

Yesterday, 09:51 AM My understanding is that it is a random type of thing; a browser hits either one of the name servers regardless of how you have them listed at your registrar.

I don't know about geo-location on name servers. I wonder if some of the services do try to act like a CDN and route name server requests to the nearest name server. From the flow charts I've seen, it is entirely random, but those could be out of date (and don't really represent the internal workings of the DNS system).

Yesterday, 10:02 AM My understanding is that it is a random type of thing; a browser hits either one of the name servers regardless of how you have them listed at your registrar. It does not work that way.

First your browser looks for information about the domain you are about to visit in your local "hosts file. If there is a record for it, it takes you there. If there is not it asks you default DNS server, which exist in the settings for current internet connection. If this DNS server has the required information about this website, your browser take it and then takes you there. In case this DNS server has not the required information, It addresses your browser to another DNS server (which have been set by the owner of the current DNS server) and it is going like that until your browser find an IP on which this domain resolves.

Now, your registrar's default DNS servers are your "authoritative" ones. If you change the backend IP of your server, this is where you should change your A-record to the new one, and depending from the TTL on your authoritative name severs, sooner or later (max 72 hours) it will goes all around the globe and any other DNS server will know your new IP address.

Yesterday, 11:29 AM Browsers don't choose, the local system does.
HOSTS, DNS cache, etc.
Yesterday, 12:19 PM Originally Posted by kpmedia Browsers don't choose, the local system does.
HOSTS, DNS cache, etc.From browser, I did not mean the actual software program, but the browsing system. In other words, how end-users find a DNS server to reach the website IP.
Yesterday, 01:02 PM His question was more likely if the OS is rotating the resolvers or just use the first one in the row/settings.
__________________
¦ QHoster.com - Instant cPanel Hosting with SSDs | Shared & Reseller in EU and US
¦ Linux and Windows RDP VPS - Locations UK, DE, CH, FR, US | OpenVPN/PPTP Enabled
¦ Instant setup | PayPal, Skrill, Payza, Bitcoin, WebMoney, Perfect Money, STP, EgoPay, OKPay
¦ Call us: (USA +1) 877 423 1155 | (UK +44) 800 610 1580 | (Skype) : qhoster Yesterday, 02:15 PM My understanding is that it is a random type of thing; a browser hits either one of the name servers regardless of how you have them listed at your registrar. It does not work that way. It work as follows:

- A client queries his ISP's nameservers.

- His ISP's nameservers query the parent dns servers for domain.com, they return it's nameservers (eg: ns1.domain.com and ns2.domain.com)

- His ISP's nameservers then query either ns1.domain.com or ns2.domain.com (choice is random) for the value of http://www.domain.com/.

- either ns1 or ns2 will return the IP address of the "www" A record for domain.com to the ISP's nameservers. The ISP's nameserver caches this value for usually about 4 hours so further queries are not required during that time. The IP is returned to the client to use to access the server.

Yesterday, 03:24 PM Not quite.

1 - the local computer, cache or query
2 - the DNS according to the computer, which may or may not be the ISP, cache or query
3 - the parents DNS query

You may not be using ISP DNS.
And the cache is always the nuisance, which is why it can takes hours to days.

The selection is then random. Often, it's using the closet one.

Yesterday, 05:15 PM
__________________
¦ QHoster.com - Instant cPanel Hosting with SSDs | Shared & Reseller in EU and US
¦ Linux and Windows RDP VPS - Locations UK, DE, CH, FR, US | OpenVPN/PPTP Enabled
¦ Instant setup | PayPal, Skrill, Payza, Bitcoin, WebMoney, Perfect Money, STP, EgoPay, OKPay
¦ Call us: (USA +1) 877 423 1155 | (UK +44) 800 610 1580 | (Skype) : qhoster Last edited by WebHostDog; Yesterday at 05:15 PM. Reason: edit Yesterday, 08:40 PM DNS, one of the very simple building blocks of the Internet is one of the most mis-understood.

DNS is nothing more than a simple, multi-distributed database that has a handful of possible record types it can return.

It has a very simple structure, where part of the data points to other parts of the data which many or may not be on different physical hosts.

Each part of the database is configured (knows) how to query other parts of the database for data that it requires but does not have.

The Application that is making a data query, simply follows the database rules.

So if we look at the structure of the Database:

The root servers. These 13 Systems have records for all of the TLD's that are publicly available. They contain Records of how to find out more specific information (They have NS/Pointer records) for each of the TLD's.

Next is the TLD's themselves (eg .com or .au). This part of the Database - the TLD databases have records again to more specific information (yes, they have NS/Pointer records as well).

A TLD then points to either ah 2LD or Domain - once again, this part of the database has records again that point to more specific information - and guess what - they again have NS/Pointer records.

Now here is where the tree-length of the database records become variable. If we are looking for a domain record (eg example.com) this part of the database will return the requested information based on the record type that was requested. Remember, i said that this database has a handful of records, well if you were looking up example.com in the database it will return the numerical address for this domain.

Now if we were a 2LD, (eg .com.au) then we would once again have those NS/pointer records to the part of the database that contains the information that we are looking for.

OK, with a basic overview of the big, world-wide distributed, database called DNS, our application (whatever that is) just needs to know the simple rules - and they are simple in how to look up that data.

What I have not covered is that at every step of the way, part of each of the records is a TTL (time to live), so that the data can be cached. The caching makes for a much more robust database - which greatly reduces the load on all the DNS database servers within the DNS database tree.

Now, lets "walk the tree"

An application will look for a cached copy on the local machine, the local machine will look for a cached copy on it's configured DNS resolvers*, the DNS resolver will look for it's cache on the 2LD or TLD. If it is not found, it will ask the root, and walk back down the tree until it finds the actual Database (on a name server somewhere in the world) that is authorative (has the data requested). Not only does the Resolver cache the result, it also caches what it finds out about the different nameservers in the tree traversal.

Now, when a cache is empty, depending on how it is configured, to return a requested record might take up to several seconds. It might have to walk the whole tree - asking the Root servers for a TLD record (and caching the answer for next time), then ask the TLD for the 2LD Record (and also caching the answer for next time), then ask the 2LD for the domain record (again caching the record according to the TTL returned as part of this record), then finally the Server that has the requested information will respond with an answer ( and again this is cached according to the TTL)

See, told you that DNS is just a trivial, caching distributed database that has some specific rules on how it is accessed. Of course, there are lots of short-cuts to this database as well and they are just local copies of a very small part of this database - and they just happen to be called host files. Host files are simply a subset of the data that is returned from the database called DNS - and usually only have the name and an IP address - they don't have the TTL or record type.

It is people who think that DNS is something other than the simple, distributed database who get confused as to what is going on.

Now, when you register a domain, it is nothing more than asking the authoritative "owner" of a TLD, 2LD etc to add a database record for you at the right point in the tree so your records for that domain can be found.

Now, why do we even need a database? pretty simple, we (humans) tend to work better with words than numbers, and DNS is just a database to convert words to numbers. Additionally, we humans are pretty clever and can make the same numbers respond in different ways to different words (think virtual hosting).

So, what's so hard about DNS?

__________________
CPanel Shared and Reseller Hosting, OpenVZ VPS Hosting. West Coast (LA) Servers and Nodes
Choose any 2: speed | reliability | cost
If you have not got a backup of your data in a geographical diverse location, you don't have a backup

View the original article here