When I buy a domain I always get confused between the two and manage to make a mess of the settings before I finally get it right, but still without clearly understanding what their roles are in helping point a domain name to the IP of my web hosting server.
The answers so far write about name servers and DNS as though they were two different things. They aren't. A DNS server is a name server. There are other name services, e.g. Corba's COSNaming, the RPC Portmapper, the Java RMI Registry, etc., but the DNS is what is usually meant.
Also contrary to what is stated in other answers, the DNS contains the DNS records.
I think in order to clarify what is going on it helps to have an overview.
The first thing to keep in mind is the internet runs on IP addresses, but people would rather remember words (domains) than numbers. This is a key problem that DNS is trying to solve. Another thing this lets you do is to change your server's IP transparently. This is great for website owners like you and me because we can change hosting providers without affecting our users ability to connect with us. So in summary DNS lets us map numbers to words (domains) which is good for both website owners and users.
With that base let me answer your question. A name server is the authoritative source to translate the name (domain) of your website into the numbers. So you need to tell the world where to go to find out the information about your domain. That information is stored with the same people that maintain the central repository of all domain names that have been purchased ICANN.org, and is searchable via their WHOIS database.
So now that we've told people where to find our name server we need to tell our name server where to send people. This "where to send people" problem is handled by our other DNS settings, like A record, AAAA records, CNAME, MX, etc.
You can visualize these things like links in a chain:
- You buy a domain name.
- You need to define the authoritative source for translating the domain name into an IP address, so you specify your name server/DNS.
- On your name server/DNS you need specify all the routing instructions that are relevant to your site, like the IP address.
- Your customers are routed successfully to your website where you earn millions of dollars and have lots of satisfied customers.
To put this in concrete terms, when you purchase a domain through a registrar they will likely default to the registrar's standard name servers.
If you're happy letting your registrar be in charge of your DNS records (most common):
- You don't need to touch the name servers
- You make all the DNS record updates (A record, CNAME, etc.) via your registrar.
If you decide that you want someone else to manage your DNS records (non-typical for small sites):
- You will have to update the name servers on your registrar to point to the name servers that the new company gives you.
- You need to make all the DNS record updates via the new company.
In simple terms:
The nameserver tells the internet where the DNS records are located e.g.
Then the DNS at
example.com tells the internet where to find different services. The A record is the IP address of the website. The MX record is the location(s) of mail servers and the order in which they should be selected.
More often than not the DNS records point to the server where they are located i.e. your website and email are hosted where the nameservers are pointing. This makes like much easier for novices.
There is a LOT more that could be included about DNS such as that there are other records for various functions, but that isn't what the question is about, so I won't add any more complexity.
The short answer is that a DNS and NS (name server) is the more or less the same thing but not really. The term Name Server refers to a role that a DNS server fulfills.
A DNS server is a form of database look-up service that assigns various records to values that are to be returned depending upon the query. Duh! Right? However, a DNS can be used for many things besides translating domain names to IP addresses and the various records associated with it. A DNS can be used for other purposes where a hierarchical scheme needs to be represented.
Be that as it may, a Name Server is a DNS server and the term Name Server applies to IP based networks in particular to the Internet. Typically, a NS holds authoritative answers to DNS queries on an IP network. The term NS is particular to the Internet since the IP protocol and DNS was developed first for the ARPA-Net then transferred to the Internet. Private IP based networks followed.
So while a NS is technically a DNS, it actually refers to the many authoritative DNS servers that return IP addresses assigned to any domain name and the associated records/values. A NS is referred to by other NS servers as being a member of the authoritative hierarchy of DNS servers beginning with the root Name Servers. Any DNS not within this defined hierarchy is merely a DNS and not a Name Server.
For example, I was a web host for a long time. I had many DNS servers, however, only two were Name Servers. While each of 5 externally available DNS servers maintained the same records, only two were queried authoritatively when someone would enter a domain name within their browser and therefore Name Servers. The remaining externally available DNS servers were non-authoritative. As well, to allow access from within the host network where external IP addresses were hosted on the router external to the host network, an Internal DNS was used. This internal DNS would contain the same records as the externally available DNS servers except that the IP addresses were internal to the host network. My point would be that while I would call the internal DNS or non-authoritative external DNSs, a DNS server, I could not rightfully call them a Name Server since they are not part of the authoritative hierarchy scheme that makes up the Internet.
One typical way to know if a DNS is a NS is to look for a SOA record when querying a domain name on the Internet. All others are merely DNS servers. To make things more confusing, any DNS can have a SOA record, however, when using
dig with the
+trace option, only the true authoritative Name Servers containing the officially recognized SOA records will be returned and not any other.
To follow from start to finish, if I wanted to add an MX record to my DNS for clients to send e-mail to me:
- I use a web interface or contact my Nameserver provider to change my records.
- Domain Name System server periodically update their HUGE database of domains > IPs by talking to Nameservers. The exact timing depends upon the setup. Sometimes it's 5 minutes, other times it can be 24-48 hours.
- Once the DNS has got my new MX record added, clients connecting to that specific DNS can now send me e-mail.
A client connects to a DNS server in order to change domain names into IP addresses. This is how you go from Example.com > '126.96.36.199'. An IP address is required to communicate with the server registered to that name.
Domain Name System (DNS) servers connect to name servers in order to compile their database. Various registrars and other services maintain lists of where to find the details of current the Domain > IP tables. Clients don't do this, only DNS servers.
When you change your nameserver, you're changing who controls your domain's records. If I change from a nameserver owned by company X to company Y, then I now have to deal with company Y when updating my records.
What are Nameservers?
Practically speaking, they are responsible for acting as a point of reference in returning the actual DNS records that map a specific domain URL (ex. www.coolsite.com) to a specific IP address (ex. 188.8.131.52).
Oversimplifying a bit, "other DNS servers" broadly act to help fulfill the general goal of returning relevant DNS records for a given domain.
What is DNS?
The Domain Name System (DNS) is a hierarchical decentralized naming system for computers, services, or other resources connected to the Internet or a private network.
Colloquially, "DNS" often refers to the process of keeping and serving your domain's particular DNS records. This includes running "Nameservers" which help provide these records to anyone who asks.
To be clear, this effectively means that "Nameservers" and "DNS" (or "DNS Servers") are often just parts of the same service.
A lot of confusion arises around the fact that almost anyone can manage your DNS records (and thus your Nameservers). But while you do need someone to do it (even if you are running the Nameservers yourself), no particular entity is intrinsically required.
Can I See Some Pretty Pictures, Please?
To help clarify, I stole a handy illustration and modified it to hopefully give a better idea of how the process of requesting an IP for your given domain (e.g. www.coolsite.com) might work:
Skipping over DNS record caching and abstracting a bit (a lot)...
The Root DNS Server (Steps 3-4) holds information about where to find the appropriate Generic Top Level Domain (gTLD) server used in Steps 5-6.
The gTLD server itself (Steps 5-6) holds information about Nameservers. In this case, we want to talk with the server that handles all the *.com domains. This is because the request is looking for www.coolsite.com and we need to know the Nameservers associated with it.
In Step 7, the request finally gets directed to your Nameservers ("DNS"). In this example, dns1.provider.com or dns2.provider.com help return a DNS record (Steps 8-9) to the client. That record might look something like:
coolsite.com. IN A 184.108.40.206 ; An "A" record e.g. an IP from ABC Hosting www IN A 220.127.116.11 ; More commonly a "CNAME" entry
This tells us that www.coolsite.com is located at 18.104.22.168 (e.g. your web hosting provider) and the client can now directly contact this IP (Step 10).
The Nameservers (Steps 7-8) can be handled by anyone -- you, your web hosting provider, your registrar, DNS-only providers, the imaginary unicorn on your couch that secretly owns a rainbow-colored server farm in the clouds...
Please note that Step 10 leaves out a lot of details ;-)
But what happens when I update my Nameserver entries?
When you update your Nameserver entries in your registrar's domain name control panel, you are (in a round about way) actually updating a gTLD server (shown previously in Steps 5-6).
Once the proper proper gTLD servers are updated with your Nameserver information, the registrar steps out of that portion of the process.
This can be confusing because many registrars now offer "DNS services" (Steps 7-8) separate from their registrar activities (e.g. helping update the gTLD servers).
To reiterate, a gTLD server (not your registrar or other DNS provider) returns the response for inquiries about your domain's Nameservers (whatever you last entered with your registrar).
DNS(Domain Name Service) is a SERVICE.
Nameservers come in many flavors.
- Root Nameservers -
A select group of nameservers that are at fixed ip addresses that are scattered throughout the world. They contain the DNS records that point to the active Top-Level-Domain(TLD) Nameservers.
Examples of TLD Domains are '.com','.org','.ca'
- Top-Level-Domain(TLD) Nameservers
These are Nameservers that contain the DNS records that point to the active list of Authoritative Nameservers for Domains of their TLD.
(Side Note - They really should be called 'subdomains' of their TLD...but most people get confused when that terminology is used...as most people are used to referring to 'google.com' as a Domain and are not used to calling 'com' a Domain)
The '.com' TLD Nameserver would have Authoritative Nameserver entries for the Domains listed below
but not for
Examples of Domains of the TLDs are 'google.com', 'amazon.com', 'google.ca'
- Authoritative Nameservers
Nameservers that contain the DNS records for a Fully Qualified Domain Name (FQDN). An example of a FQDN is 'www.google.com'. It contains both a 'host' portion (the 'www') and a Domain portion (the 'google.com').
Examples of the types of record present on an Authoritative Nameserver would be - 'SOA' record which contains a serial number that is used for revision control of all records in the domain, amongst other things.
(SOA = Start of Authority record) - 'A' record which contains the ip address associated with a 'hostname'. An example of a hostname would be 'www'. The 'hostname' is assumed to have the domain concatenated to the end of it UNLESS the hostname ends with a '.'
(A = Address record)
There are many other DNS records possible but they do not add anything to this answer. Each if these records has a field that designates the 'Time-To-Live' (TTL) which is the minimum number of seconds a Caching Nameserver is supposed to cache the record.
- Caching Nameservers
These nameservers typically have no authoritative records. They receive DNS queries from users and have the ability to recursively walk the DNS structure outlined above to resolve an 'FQDN' to an 'IP' For example we typically say
- The FQDN 'www.google.ca'
- the IP '22.214.171.124'
It will store this record lookup for a defined period of time(the TTL) along with the SOA record for the related Domain. During this defined period of time the Caching Nameserver will respond to any additional user queries for the same FQDN with the IP it has in it's cache.
After the defined period of time if a user queries for the same FQDN the Caching Nameserver will walk the DNS structure outlined above and first fetch the SOA record for the domain. If the serialnumber of the SOA record matches what it has in it's cache then it assumes there have been no changes in any DNS records for that Domain so it will simply retain and forward the already cached result on to the user and extend the cache lifetime by another TTL seconds.
A common error of first time DNS maintainers is to NOT UPDATE the SOA record serial number after making DNS changes.