When buying a domain what are the differences between nameservers (NS records) and other DNS servers?

Question

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.

Answer 1

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.

Answer 2

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:

1. You buy a domain name.
2. You need to define the authoritative source for translating the domain name into an IP address, so you specify your name server/DNS.
3. On your name server/DNS you need specify all the routing instructions that are relevant to your site, like the IP address.
4. 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.

Answer 3

In simple terms:

The nameserver tells the internet where the DNS records are located e.g. ns1.example.com and ns2.example.com

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.

Answer 4

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.

Answer 5

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:

1. I use a web interface or contact my Nameserver provider to change my records.
2. 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.
3. 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 > '11.22.33.44'. 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.

Answer 6

What are Nameservers?

In the context of managing your domain(s), Nameservers are authoritative DNS name servers for your domain (e.g. coolsite.com). They have NS records.

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. 99.100.101.102).

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?

Per Wikipedia:

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    99.100.101.102  ; An "A" record e.g. an IP from ABC Hosting
  www             IN A    99.100.101.102  ; More commonly a "CNAME" entry
  

  This tells us that www.coolsite.com is located at 99.100.101.102 (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).

Ex. Registrar Domain Control Panel (Nameservers)

Ex. What Registrars Domain Control Panels Actually Update (Nameservers)

Answer 7

DNS(Domain Name Service) is a SERVICE.

Nameservers come in many flavors.

1. 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'

2. 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

• google.com
• amazon.com

  but not for

• google.ca

Examples of Domains of the TLDs are 'google.com', 'amazon.com', 'google.ca'

3. 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.

4. 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'

  resolves to

• the IP '172.217.0.99'

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.

Answer 8

While most answers get to the core of it (DNS and NS can often be just synonyms, it depends on the context, if we know we are in the domain name business, the D for Domain is not adding more information), I think there is one point not addressed which may or may not be related to your question, but its phrasing is not 100% clear and it comes maybe also from an unclear UI at your registrar.

For terminology in the "DNS" world, please now refer to RFC 8499 "DNS Terminology". The terms "in-domain" and "in-bailiwick" are defined in it.

Authoritative nameservers on the domain

When you register a domain name, or later update it, you can specify a set of nameservers that will be authoritative for it. This is at least a set of names, but in some cases (see below) also associated IP addresses of those names that point to specific host names where a DNS server is running and properly configures to answer on queries about this domain name.

"Attaching" nameservers to a domain is necessary to make it appear on the worldwide Internet so that its enclosed services (website, emails, etc.) are resolved and hence can be reached. It is however not mandatory, you can totally have a domain name without (authoritative) nameservers attached to it. It is like you parked the domain: it is registered, no one else can have it, but it has no running services reachable.

In-bailiwick nameservers

Completely separated from the previous case, as soon as you register a domain name, such as example.com, you can have nameservers below it or in it if you want: you can give to some host the name i-am-a-nameserver.example.com. If you want that name to resolve, of course example.com needs to have authoritative nameservers. But i-am-a-nameserver.example.com can be a nameserver for any domain, such as something-completely-different.example.

Now the important point is the following: in most (but not all) TLDs, a nameserver (or host, in this context) is handled as an object, and as such must be created in the registry database, like any domain or contact, and this happens through a registrar (either the registrar sponsoring the specific domain under which you wish to create a nameserver object if this domain is at this registry, or any other registrar if you try to create an "external" nameserver object, that is if you want to create ns.example.net where you are in fact in the .example TLD registry).

Which may explain why at some registrar you will have a section called "Register a nameserver" or something close to that. It will be to create nameserver host objects at the registry, under any of your domain name.

This is maybe where the distinction was done on what you saw or maybe your confusion.

Note that you need to consult this section normally only if you need to create "extra" nameservers: any registrar, when you ask it to register example.com with nameservers ns1.hello.example and ns2.foobar.example, with automatically create (if necessary) the 2 nameservers objects at registry before creating the domains or at least before associating those nameservers to the domain (nameserver objects need to exist before being able to use them and attach them as authoritative to your domain name).

But for any other extra nameservers, you can use this section at your registrar to create the nameservers.

In-domain nameservers

Now the plot thickens, and we "merge" the two previous cases: you can register domain name example.com AND use as authoritative nameserver for it ns.example.com (or any other name "below" example.com, and in fact example.com could also be a valid hostname for a nameserver but this really a case you will prefer to avoid).

This has benefits and drawbacks. Among the drawbacks you have the consequence that this means, for the resolution to operate properly, that the registry needs to publish a "glue record" which means nothing else than publishing the IP addresses of ns.example.com at its level (the parent zone of example.com). For that to happen, through the registrar, you need to register the nameserver object ns.example.com with IP addresses. Of course if they change, you will need to update them at registry side too, and missing synchronization there is a frequent reason of such setups starting to misbehave.

With your specific registrar

You said

When I buy a domain I always get confused between the two

But without specifying the registrar, so no one could give you specific instructions for its specific UI.

Did you maybe ask it for instructions or at least to report back that its UI confuses you? Did you try to look at other registrars' UI? Maybe another one would provide you with a better experience?

Registrar ≠ DNS provider

As for

helping point a domain name to the IP of my web hosting server. this adds another level of complexity or subtlety in the problem and hence the answer.

If you go back at above paragraph about Authoritative nameservers, we said you need to provide some (often 2) authoritative nameservers to be attached to your domain so that it resolves and hence make all services on the domain work on the Internet.

Now, these nameservers are run by some entity. This entity can be called a DNS provider since its job is to provide running nameservers for anyone that wants to use them. This entity can be the registrar but does not need to be the registrar.

As soon as the domain name is configured to use a specific set of nameservers as authoritative, for any change in the content of the zone (such as "point a domain name to the IP of my web hosting server"), then you need to do things through the DNS provider UI, not through your registrar.

You go to your registrar to set or change the nameservers authoritative for your domain. You go to your DNS provider to change the content of the zone such as specifying the IP address of your website.

Many, if not all, registrars provide DNS service (for free or not) and hence you can use them, if you want. The immediate benefit normally is that you have a single destination to go to to manage everything you need. The immediate drawback is that you have a single destination to go to to manage everything you need, which means no choices (regarding service levels, prices, etc.) and bigger problems in case you have either a technical or legal problem with that specific entity.

Maybe you were also talking about registrar's UI (being a DNS provider) being confusing to you when you tried to add an A record (which is what is needed to point a name to an IPv4 address).