The DNS is the system which converts Internet domain names, such as www.netnod.se, into numeric addresses such as 212.237.144.84 or 2a07:2180:0:1::400. DNS includes a hierarchy of “authoritative name servers”, each level of which contains different pieces of information. To translate www.netnod.se, a resolver – the name server a user queries directly – first has to figure out where .se is, then netnod.se, and finally www.netnod.se.


The authoritative name servers that the resolvers use to find top level Domains (like .se) are the root name servers.

The root zone
The root servers contain the information that makes up the root zone, which is the global list of top level domains. The root zone contains:

•    generic top level domains – such as .com, .net, and .org

•    country code top level domains – two-letter codes for each country, such as .se for Sweden or .no for Norway

•    internationalized top level domains – generally equivalents of country code top level domain names written in the countries’ local character sets

For each of those top level domains, the root zone contains the numeric addresses of name servers which serve the top level domain’s contents, and the root servers respond with these addresses when asked about a top level domain.

Who operates them?
The root servers are operated by 12 different organizations:

A VeriSign Global Registry Services
B University of Southern California, Information Sciences Institute
C Cogent Communications
D University of Maryland
E NASA Ames Research Center
F Internet Systems Consortium, Inc.
G US DoD Network Information Center
H US Army Research Lab
I Netnod
J VeriSign Global Registry Services
K RIPE NCC
L ICANN
M WIDE Project
Many of these organizations have been operating root servers since the creation of the DNS. The list shows the Internet’s early roots as a US-based research and military network.



Where they are?
There are more than 750 root server instances around the world, on all six populated continents. They are reachable using 13 numeric IP addresses – one per operating organisation, except for Verisign, which operates two root servers. Most of those addresses are assigned to multiple servers around the world, so DNS queries sent to those addresses get fast responses from local servers. This was not always the case. Before 2004, there were root server instances in only 13 locations – one per IP address – and all but three were in the United States. However, significant efforts by several of the root server operators, including Netnod, have expanded the global root server footprint since then.

Because there are only 13 root server IP addresses, only 13 root servers can be seen from any single location at any given time. Different servers (using the same IP addresses) will be seen from different locations.

Who is responsible for them?
Each operating organization is solely responsible for the root server IP address (or addresses) it operates. The operating organization determines how many locations that IP address will be served from, what those locations are, what hardware and software will be installed in each location, and how that hardware and software will be maintained. Some operators operate only a single location, while others operate many (one operator is responsible for almost 100). Each organization secures its own operating funds.

Where does the root zone come from?
The root zone comes from the Internet Assigned Numbers Authority (IANA), which is part of the Internet Corporation for Assigned Names and Numbers (ICANN). It is signed using DNSSEC signatures to ensure authenticity, and issued to the root server operators to publish to their root servers. The root server operators publish the root zone as written, and have no authority to alter the content.

How do resolvers find root servers?
Since root servers are at the root of the DNS hierarchy, it isn’t possible to walk through the DNS hierarchy to find them: the resolvers wouldn’t know where to look. Instead, there is a list of well-known and rarely changed root server IP addresses, and every DNS resolver has that list of IP addresses included with the software. If a root server does need to change addresses – something that has happened multiple times over the years – this does not present a significant problem. Older resolvers continue to work by using the other 12 root server addresses, and their list gets updated when their software is updated.

Fault tolerance
While root servers are critical infrastructure, the failure of a single root server won’t be noticed by most Internet users. Individual servers that fail should withdraw their address announcements, allowing queries to be answered by a different server responding to the same address. If all instances of a single address are unreachable, either in general or for a specific part of the world, there are 12 more root server IP addresses to choose from. The  chances of all 750+ root server instances or all 13 root server IP addresses being unreachable at the same time are very small, and the root server system is, thus, very reliable.

DDNS stands for dynamic DNS, or more specifically dynamic Domain Name System. It's a service that maps internet domain names to IP addresses. It's a DDNS service that lets you access your home computer from anywhere in the world.


DDNS serves a similar purpose to the internet's Domain Name System (DNS) in that DDNS lets anyone hosting a web or FTP server advertise a public name to prospective users.

However, unlike DNS that only works with static IP addresses, DDNS is designed to also support dynamic (changing) IP addresses, such as those assigned by a DHCP server. That makes DDNS a good fit for home networks, which normally receive dynamic public IP addresses from their internet provider.

Note: DDNS is not the same as DDoS even though they share most of the same acronym letters.

How a DDNS Service Works
To use DDNS, just sign up with a dynamic DNS provider and install their software on the host computer. The host computer is whichever computer is used as the server, be it a file server, web server, etc.

What the software does is monitors the dynamic IP address for changes. When the address changes (which it eventually will, by definition), the software contacts the DDNS service to update your account with the new IP address.

This means so long as the DDNS software is always running and can detect a change in the IP address, the DDNS name you have associated with your account will continue to direct visitors to the host server no matter how many times the IP address changes.


The reason a DDNS service is unnecessary for networks that have static IP addresses is because the domain name doesn't need to know what the IP address is after it's initially told of it the first time. This is because static addresses don't change.

Why You Might Want a DDNS Service
A DDNS service is perfect if you host your own website from home, you have files you want to access no matter where you are, you like to remote into your computer when you're away, you like to manage your home network from afar, or any other similar reason.

Where to Get a Free or Paid DDNS Service
Several online providers offer free DDNS subscription services that support Windows, Mac, or Linux computers. A couple of my favorites include FreeDNS Afraid and NoIP.

However, something you should know about free DDNS service is that you can't just choose any URL and expect to have it forwarded to your server. For instance, you can't pick files.google.org as your file server address. Instead, after choosing a hostname, you're given a limited selection of domains to choose from.

For example, if you use NoIP as your DDNS service, you can pick a hostname that's your name or some random word or mixture of words, like my1website, but the free domain options are hopto.org, zapto.org, systes.net, and ddns.net. So, if you chose hopto.org, your DDNS URL would be my1website.hopto.org.

Other providers like Dyn offer paid options. Google Domains includes dynamic DNS support, too.

Reverse DNS is IP address to domain name mapping - the opposite of forward (normal) DNS which maps domain names to IP addresses.

Reverse DNS is separate from forward DNS.
Forward DNS for "abc.com" pointing to IP address "1.2.3.4", does not necessarily mean that reverse DNS for IP "1.2.3.4" also points to "abc.com".
This comes from two separate sets of data.


A special PTR-record type is used to store reverse DNS entries. The name of the PTR-record is the IP address with the segments reversed + ".in-addr.arpa".
For example the reverse DNS entry for IP 1.2.3.4 would be stored as a PTR-record for "4.3.2.1.in-addr.arpa".

Reverse DNS is also different from forward DNS in who points the zone (domain name) to your DNS server.
With forward DNS, you point the zone to your DNS server by registering that domain name with a registrar.
With reverse DNS, your Internet connection provider (ISP) must point (or "sub-delegate") the zone ("....in-addr.arpa") to your DNS server.
Without this sub-delegation from your ISP, your reverse zone will not work.

Reverse DNS is mostly used by humans for such things as tracking where a web-site visitor came from, or where an e-mail message originated etc.
It is typically not as critical in as forward DNS - visitors will still reach your web-site just fine without any reverse DNS for your web-server IP or the visitor's IP.

However reverse DNS is important for one particular application.
Many e-mail servers on the Internet are configured to reject incoming e-mails from any IP address which does not have reverse DNS.
So if you run your own e-mail server, reverse DNS must exist for the IP address that outgoing e-mail is sent from.
It does not matter what the reverse DNS record for your IP address points to as long as it is there. If you host multiple domains on one e-mail server, just setup reverse DNS to point to whichever domain name you consider primary.
(e-mail servers checking for reverse DNS do recognize that it is normal to host many domains on a single IP address and it would be impossible to list all those domains in reverse DNS for the IP).

Special note about AOL:
It appears that AOL has recently restricted this even further:
They also require that reverse DNS points to a "fully qualified domain name" (we assume they mean a name with 3 or more segments, such as "mail.jhsoft.com"), and that this name does not contain the segments "in-addr.arpa" and is not just an IP address.
If you want to be able to send e-mail to AOL users, the reverse DNS record for your e-mail server IP address must adhere to this as well.

Round Robin DNS is a technique of load distribution, load balancing, or fault-tolerance provisioning multiple, redundant Internet Protocol service hosts, e.g., Web server, FTP servers, by managing the Domain Name System's (DNS) responses to address requests from client computers according to an appropriate statistical model.


In its simplest implementation, Round-robin DNS works by responding to DNS requests not only with a single potential IP address, but with one out of a list of potential IP addresses corresponding to several servers that host identical services. The order in which IP addresses from the list are returned is the basis for the term round robin. With each DNS response, the IP address sequence in the list is permuted. Usually, basic IP clients attempt connections with the first address returned from a DNS query, so that on different connection attempts, clients would receive service from different providers, thus distributing the overall load among servers.

There is no standard procedure for deciding which address will be used by the requesting application, a few resolvers attempt to re-order the list to give priority to numerically "closer" networks. Some desktop clients do try alternate addresses after a connection timeout of 30–45 seconds.

Round robin DNS is often used to load balance requests between a number of Web servers. For example, a company has one domain name and three identical copies of the same web site residing on three servers with three different IP addresses. When one user accesses the home page it will be sent to the first IP address. The second user who accesses the home page will be sent to the next IP address, and the third user will be sent to the third IP address. In each case, once the IP address is given out, it goes to the end of the list. The fourth user, therefore, will be sent to the first IP address, and so forth.

A round-robin DNS name is, on rare occasions, referred to as a "rotor" due to the rotation between alternative A records.

A load balancing technique in which balance power is placed in the DNS server instead of a strictly dedicated machine as other loadtechniques do.

Round robin works on a rotating basis in that one server IP addressis handed out, then moves to the back of the list; the next server IP address is handed out, and then it moves to the end of the list; and so on, depending on the number of servers being used. This works in a looping fashion.

Round robin DNS is usually used for balancing the load of geographically distributed Web servers. For example, a company has one domain name and three identical home pages residing on three servers with three different IP addresses. When one user accesses the home page it will be sent to the first IP address. The second user who accesses the home page will be sent to the next IP address, and the third user will be sent to the third IP address. In each case, once the IP address is given out, it goes to the end of the list. The fourth user, therefore, will be sent to the first IP address, and so forth.

In this article, we’re discussing a few of the more commonly used record types and when you might use them.


A Records
A Records are the most basic type of DNS record and are used to point a domain or subdomain to an IP address. Assigning a value to an A record is as simple as providing your DNS management panel with an IP address to where the domain or subdomain should point and a TTL.

A Record listing in the GoDaddy DNS Management Panel.
A Record listing in the GoDaddy DNS Management Panel.

The screenshot above is a sample of A Record listings of different types. You can see that the wildcard ( * ), @ symbol, and named host name entries were used. Here, the primary naked domain record (@) and blog subdomain point at the same IP address, but are separate records and can be changed individually at any time. A Records are only able to take an IP address as their value and you can point the same domain/subdomain to multiple IP addresses by adding another A Record with the same name but with a different IP address for the value.

You’ll want to use an A Record for your DNS entry if you have an IP address that the domain/subdomain should point to or if you want to establish a domain/subdomain to be used as the place to point a CNAME. You can find out more about why you might want to do this in the CNAME portion of this article.

CNAME
CNAME records are another commonly used type of DNS entry and are used to point a domain or subdomain to another hostname.

CNAME record listing in the GoDaddy DNS Management Panel.
CNAME record listing in the GoDaddy DNS Management Panel.

In the screenshot above, you can see immediately that one of the important differences from A Records is that the value portion of the record is required to be an existing subdomain/domain. You can see that the “journal” hostname points to my blog.iamrobertv.com A Record, which points to 198.101.164.57. What this means is that, if the value of the blog’s subdomain is ever changed, the journal subdomain’s value will also be changed.

As a host, we can use CNAMEs for customers as a means of being able to change the IP address of a server or cluster of servers transparently and without users having to make their own DNS adjustments. You can see an example of this in the store hostname that points to a cluster of servers of servers that sit behind the thor.openhostingservice.com subdomain. Finally, you can see the use of the @ symbol to indicate that the www hostname should point to the naked domain and use its value, which when you see the A Record sample image above, points to 198.101.164.57. This also means that, if the value of the naked/primary domain changes, the record of www will end up being affected accordingly.

MX Record
Mail Exchanger (MX) records are used to help route email according to the domain owners preference. The MX record itself specifies which server(s) to attempt to use to deliver mail to when this type of request is made to the domain. They differ from A Records and CNAMEs in the way that they also require a “priority” value as a part of their entry. The priority number is used to indicate which of the servers listed as MX records it should attempt to use first.

mx_record

In the screenshot above, you can see that I am using two MX records that have separate priority values and point to different subdomains. These subdomains are pointed at two different email servers that are designated to handle email. The MX record with the lower priority number (“0” in this case) is the first to be tried for email delivery. If this server is unable to handle the mail request, the next lowest priority number is used, which in this case would be 10.

Some email providers have only one MX record and some have well over two. The number of MX entries you will need to create depends largely on the mail provider and how they expect the load on these email servers to be handled.

Try the BEST WordPress hosting free for 15 days. Use code PRESS50OFFFOR2 at checkout and get 50% off your first 2 months.

You will notice the host name here is designated as the naked/primary form ( @ ). If you wanted to receive mail on a subdomain, you would adjust the hostname accordingly and ensure your email provider is setup to handle email from the subdomain.

TXT Record
A TXT record is used to store any text-based information that can be grabbed when necessary. We most commonly see TXT records used to hold SPF data and verify domain ownership.

TXT Record listing in the GoDaddy DNS Management Panel.
TXT Record listing in the GoDaddy DNS Management Panel.

The screenshot above gives an example of how a TXT value would be formed for both an SPF entry or an ownership verification for the naked/primary host/name using the @ symbol. If you need to verify or provide an SPF record for a specific subdomain, then you will need to use the appropriate hostname in place of the @ symbol. The rule of thumb for TXT records is that they require an attribute name, followed by an equals sign, followed by a value for the attribute. You can use this to relay any sort of information you’d like using a DNS record, so long as you have a purpose for it and the record is properly formatted.

We won’t go into the details of properly formed SPF records and what their different pieces mean, but these will commonly be supplied to you by the mail provider you are working with. In the same way, places that require domain verification through use of a TXT record will also provide you with a properly formatted TXT record value to use.

Final Thoughts
Managing your own DNS can be a tricky endeavor, especially if you haven’t ever considered what this means or ever even seen a DNS record. Ideally, this series of articles will help you understand the general how a website’s DNS works for a domain from the time it is typed into the browser to the time your name servers handle the request. Although it can be rather easy to understand the record types themselves, knowing about nameservers, registrars, and how a specific set of DNS records gets chosen and used is a little more difficult to navigate, but is just as essential to know.

A couple days ago, Cloudflare launched its own DNS service at 1.1.1.1, promising that consumers would enjoy greater privacy and potentially faster internet if they switched over from their ISP’s default. Now, those speed differences might not be significant or noticeable enough to the point of making the switch full-time. (We’re talking milliseconds here.) But it doesn’t take many steps to test out a new DNS, so it’s probably worth a quick try if you’re curious or sold on Cloudflare’s privacy measures.


The Domain Name System (DNS) is what converts domain names into IP addresses. And the best way to change your DNS is by adjusting your router’s settings. This automatically makes any devices joining your Wi-Fi network use the new DNS without having to go in and configure each device individually. It’s just a much easier approach.

WHAT ARE SOME POPULAR DNS OPTIONS BESIDES MY ISP’S DEFAULT?
Google Public DNS:

Primary: 8.8.8.8
Secondary: 8.8.4.4

OpenDNS

Primary: 208.67.222.222
Secondary: 208.67.220.220

Cloudflare

Primary: 1.1.1.1
Secondary: 1.0.0.1

CHANGE DNS FOR ALL DEVICES THAT CONNECT TO YOUR ROUTER (BEST OPTION)
Linksys

Sign in to your Linksys router’s admin page, which is almost certainly 192.168.1.1. Click “Setup” from the top menu. From there, choose “Basic Setup,” and enter the new DNS info into the Status DNS 1 and 2 fields. Save settings, and you’re done. You shouldn’t need to reset your router for the change to take effect.

Netgear

When connected to your Wi-Fi, visit http://www.routerlogin.com or http://www.routerlogin.net in a web browser. Log in with your administrator credentials. Click “Internet” and then select “Use these DNS Servers” and enter the primary and secondary addresses. Then click “Apply.” Done.

D-Link

Open your router administration page at wither 192.168.1.1 or 192.168.0.1. Log in with your password, and then choose “Manual Internet Connection Setup.” Fill in the DNS server fields with the primary and secondary DNS addresses.

Google Wifi

Open the Google Wifi app, go to the settings tab, then pick “networking & general.” Tap on advanced network, and then DNS. Choose “custom,” and then enter your new primary and secondary DNS addresses.

Eero

From the Network Settings page, to go Advanced, then choose DNS. Tap “Custom DNS,” and enter your primary and secondary DNS.

CHANGE DNS FOR INDIVIDUAL DEVICES
Windows

Open the Control Panel. Click on Network and Internet, and then Network and Sharing Center. Choose “Change Adapter Settings” from the list on the left.

Next, right click on whatever Wi-Fi network you’re currently on, and choose Properties. Select Internet Protocol Version 4 (TCP/IPv4), and then click Properties.

Click “Use The Following DNS Server Addresses,” and replace whatever’s there with your new DNS. In the case of Cloudflare, you’d enter 1.1.1.1 and 1.0.0.1. Click OK, followed by Close, and you’re done.

Android

Android requires a static IP address to use custom DNS addresses, which takes additional setup steps. The router approach is recommended here.

If you’ve already done that, go to settings, then Wi-Fi. Long-press on your current Wi-Fi network and choose “Modify Network.” You might need to go to an advanced section depending on your Android device’s software. Add your new primary and secondary DNS addresses to the DNS 1 and DNS 2 fields.

iOS

Go to settings. Pick Wi-Fi, then tap the blue “i” next to your preferred network. Tap “Configure DNS” and make sure it’s set to manual, not automatic. Then delete any entries under DNS services and choose “Add Server” to enter your new DNS resolver. Using Google Public DNS as an example, you would add two entries: 8.8.8.8 and 8.8.4.4. Save your changes, and you’re done.

macOS

Open System Preferences. Instead of clicking through numerous menus, the fastest way to get where you want to be is just by searching for “DNS servers” at the top right. That’ll take you to the right screen, where you can click the + symbol to add whichever DNS you want to try.

A, CNAME, ALIAS and URL records are all possible solutions to point a host name (name hereafter) to your site. However, they have some small differences that affect how the client will reach your site.


Before going further into the details, it’s important to know that A and CNAME records are standard DNS records, whilst ALIAS and URL records are custom DNS records provided by DNSimple’s DNS hosting. Both of them are translated internally into A records to ensure compatibility with the DNS protocol.

Understanding the differences
Here’s the main differences:

The A record maps a name to one or more IP addresses, when the IP are known and stable.
The CNAME record maps a name to another name. It should only be used when there are no other records on that name.
The ALIAS record maps a name to another name, but in turns it can coexist with other records on that name.
The URL record redirects the name to the target name using the HTTP 301 status code.
Some important rules to keep in mind:

The A, CNAME, ALIAS records causes a name to resolve to an IP. Vice-versa, the URL record redirects the name to a destination. The URL record is simple and effective way to apply a redirect for a name to another name, for example to redirect www.example.com to example.com.
The A name must resolve to an IP, the CNAME and ALIAS record must point to a name.
Which one to use
Understanding the difference between the A name and the CNAME records will help you to decide.

The general rule is:

use an A record if you manage what IP addresses are assigned to a particular machine or if the IP are fixed (this is the most common case)
use a CNAME record if you want to alias a name to another name, and you don’t need other records (such as MX records for emails) for the same name
use an ALIAS record if you are trying to alias the root domain (apex zone) or if you need other records for the same name
use the URL record if you want the name to redirect (change address) instead of resolving to a destination.