Why is DNS important?
DNS is like a phone book for the Internet. If you know a person’s name but don’t know their telephone number, you can simply look it up in a phone book. DNS provides this same service to the Internet.
When you visit http://facebook.com in a browser, your computer uses DNS to retrieve the website’s IP address of 220.127.116.11. Without DNS, you would only be able to visit our website (or any website) by visiting its IP address directly, such as http://18.104.22.168.
rupin@L687:~$ ping facebook.com PING facebook.com (22.214.171.124) 56(84) bytes of data. 64 bytes from edge-star-mini-shv-01-iad3.facebook.com (126.96.36.199): icmp_seq=1 ttl=42 time=347 ms
When a linux computer looks for another computer IP it looks for the information in two files : /etc/hosts and /etc/resolv.conf. The order in which the files are consulted is configured on /etc/nsswitch.conf:
$ cat /etc/nsswitch.conf
Search first on files (/etc/hosts) and then on dns (/etc/resolv.conf).
This file is a simple database that relates a numeric IP with a hostname. It can be edited as a normal file with ‘vi’ command in order to add more information.
# cat /etc/hosts 127.0.0.1 localhost.localdomain localhost 192.168.1.1 rupin.server.com server
The first line maps the 127.0.0.1 IP to the hostnames localhost, short hostname, and localhost.localdomain, FQHN hostname. The second line maps the 192.168.1.1 IP to server and rupin.server.com hostname.
In order to configure a linux computer as a DNS client the file /etc/resolv.conf must be used.
# cat /etc/resolv.conf search info.net nameserver 192.168.1.1
In this case all DNS queries launched from the computer will be addressed to the nameserver on 192.168.1.1. If a short hostname is provided it will be complemented automatically with ‘info.net’ domain.
Note: By default if a DNS query is done and can be answered from /etc/hosts the nameserver configured on /etc/resolv.conf is not consulted. Only the information obtained from /etc/hosts is taken as valid.
How DNS works:
The DNS is the default name resolution service used in UNIX (configurable option) and Windows servers.
However, when the Internet was very small, host name resolution was done using /etc/hosts file under UNIX. The hosts file is a computer file used by an operating system to map host names to IP addresses. MS-Windows also support the hosts file and usually locate at %SystemRoot%\system32\drivers\etc\ directory.
However, these days Domain Name System is the default name resolution service used in all operating systems including mobile phones such as Apple iPhone. DNS is part of the operating system and all TCP/IP network connections are, by default, configured with the IP address of at least two DNS server to perform name resolution on the network.
There have been various implementation of DNS over the years. UNIX systems typically use BIND (Berkeley Internet Name Domain) or djbdns. Microsoft Windows Server operating systems typically use a non-Active Directory, or standard, Domain Name System solution. However, various implementations use the same protocols for exchanging DNS information over the Internet.
How does DNS works?
The domain name system of the INTERNET works in a inverted tree structure.At the top of the tree is the root name server.The root server is followed by TLD’s or Top Level Domains,and then TLD’s are followed by SLD’s or Second Level Domains. All of these are separated by dots.
TLD’s are split into two types:
Generic Top Level Domains(gTLD’s) are TLD’s like .com,.net,.org,.edu etc.
Country Code Top Level Domains are domains such as .in,.us,.uk etc.
When we normally call a domain like google.com its the combination of TLD,SLD.
Each and every node in this Domain Name system is assigned to an authority or organization for its administration. And that organization resposible for a particular node is authoritative for that node.The term authoritative will be used many times in DNS system.
Now the authority of the .(root name server) which is at the top of the heirarchy lies with an organization named ICANN(Internet Corporation for Assigned Names And Numbers.).
gTLD’s like (.com,.net) and others are also administered by ICANN and are also delegated to ICANN accredited registrars. ccTLD’s are accredited to different countries for administration by ICANN.
what happens when I type http://www.example.com in the address bar of the browser?
The root name server(.) is the most important resource in the name server hierarchy. when any name server is asked for an information which it does not have, the first thing that name server does is asking one of the (.)root name server.
there are 13 root name servers as follows.
a.root-servers.net. b.root-servers.net. c.root-servers.net. d.root-servers.net. e.root-servers.net. f.root-servers.net. g.root-servers.net. h.root-servers.net. i.root-servers.net. j.root-servers.net. k.root-servers.net. l.root-servers.net. m.root-servers.net.
Now the ip address of all the root servers mentioned above are known to all the DNS software packages, by default. Which means all the DNS servers can reach these root servers without any other DNS server.
Step1: the client types http://www.example.com in his browser.
Step2: the operating system looks at /etc/host file,first for the ip address of http://www.example.com(this can be changed from /etc/nsswitch), then looks /etc/resolv.conf for the DNS server IP for that machine.
Step3: the dns server will search its database for the name http://www.example.com, if it finds it will give that back, if not it will query the root server(.) for the information.
Step4: root server will return a referral to the .com TLD name server(these TLD name servers knows the address of name servers of all SLD’s).In our case we searched for http://www.example.com so root server will give us referral to .com TLD servers.
If it was http://www.example.net then root server will give, .net TLD servers refferal.
Step5: Now One of the TLD servers of .com will give us the referral to the DNS server resposible for example.com domain.
Step6: the dns server for example.com domain will now give the client the ip address of www host(www is the host name.).
Now lets practically have a look at how this process works.
[root@localhost ~]# dig +trace example.com ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> +trace example.com ;; global options: printcmd . 76094 IN NS b.root-servers.net. . 76094 IN NS e.root-servers.net. . 76094 IN NS j.root-servers.net. . 76094 IN NS g.root-servers.net. . 76094 IN NS i.root-servers.net. . 76094 IN NS h.root-servers.net. . 76094 IN NS c.root-servers.net. . 76094 IN NS m.root-servers.net. . 76094 IN NS l.root-servers.net. . 76094 IN NS f.root-servers.net. . 76094 IN NS d.root-servers.net. . 76094 IN NS k.root-servers.net. . 76094 IN NS a.root-servers.net. ;; Received 497 bytes from 172.16.140.34#53(172.16.140.34) in 0 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. ;; Received 489 bytes from 188.8.131.52#53(b.root-servers.net) in 284 ms example.com. 172800 IN NS a.iana-servers.net. example.com. 172800 IN NS b.iana-servers.net. ;; Received 165 bytes from 184.108.40.206#53(a.gtld-servers.net) in 226 ms example.com. 172800 IN A 220.127.116.11 example.com. 172800 IN NS b.iana-servers.net. example.com. 172800 IN NS a.iana-servers.net. ;; Received 93 bytes from 18.104.22.168#53(a.iana-servers.net) in 100 ms
One major thing to understand here in the above shown trace query is the fact that, when you do a dig +trace,your local dns server (the server mentioned in resolv.conf), will only provide you with address of the 13 dns root servers. Rest of the job of fetching the A record for example.com is done by the dig tool itself. Whichis evident from the output.
If you simply follow the output of the trace, you will come to know the flow of the query. The first result One major thing to understand here in the above shown trace query is the fact that, when you do a dig +trace, your local dns server (the server mentioned in resolv.conf), will only provide you with address of the 13 dns root servers.Rest of the job of fetching the A record for example.com is done by the dig tool itself. Which is evident from the output.
If you simply follow the output of the trace, you will come to know the flow of the query. The first result shows that your local DNS server provided the address of the 13 root servers to select from, which is clear by the below line.shows that your local DNS server provided the address of the 13 root servers to select from, which is clear by the
;; Received 497 bytes from 172.16.140.34#53(172.16.140.34) in 0 ms
Now dig will select one root server from the 13, to fetch the address of the .COM TLD servers. So the root server selected will reply with the .COM TLD server addresses, which is clear by the below part in the trace result.
com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. ;; Received 489 bytes from 22.214.171.124#53(b.root-servers.net) in 284 ms
The above line clearly mentions that the COM server addresses are provided by b.root-servers.net or 126.96.36.199(which is one of the 13 root server).
Now from the COM server addresses given, one of them is selected to return the name servers for the domain example.com which is shown below.
example.com. 172800 IN NS a.iana-servers.net. example.com. 172800 IN NS b.iana-servers.net. ;; Received 165 bytes from 188.8.131.52#53(a.gtld-servers.net) in 226 ms
The last line indicates that the COM GTLD server named a.gtld-servers.net with the ip address of 184.108.40.206 replied us with the name servers responsible for the domain example.com. Which means the two name servers mentioned in the answer a.iana-servers.net & b.iana-servers.net, are the authoritative name server for the domain name
Which means these two name server will the one, that contains answers for all records related to example.com domain.Again from those two, one of them will be selected, and will reply us with the A record for example.com, which is clear from the final part of the trace output.
example.com. 172800 IN A 220.127.116.11 example.com. 172800 IN NS b.iana-servers.net. example.com. 172800 IN NS a.iana-servers.net. ;; Received 93 bytes from 18.104.22.168#53(a.iana-servers.net) in 100 ms
which means example.com has got an A record of 22.214.171.124, which was given to us by the server126.96.36.199 or a.iana-servers.net (which is responsible for the complete dns records for the domain example.com).
So the translating computer will begin its job from right to left, with
dot com example www.
The first dot, indicates root servers.There are 13 IP addresses/number of these DOT
server’s that every DNS software’s already know by default.
why that number is 13 IP and not more
The main reason is because when you plan a big architecture like DNS root server’s, you need to go into several depths to analyse performance issues. So as i said there are 13 IP addresses. If you are a networking guy or a system administrator, you might already know that UDP is better than TCP where performance is the requirement.And due to performance issues, a UDP packet used for DNS is limited to 512 bytes, if your payload goes above 512 bytes, then TCP will be used.
TCP involves very high overhead, because it includes multiple steps and procedures to establish a TCP connection,that can slow the entire process.The first one is better suited for reliability and the second one is suited for performance. Things like DNS should never be slow, hence it by default works on UDP. And a single UDP packet should contain all this 13 IP addresses along with other UDP protocol information (416 bytes of 13 ip addresses and remaining protocol information of UDP). Yeah sure you can easily have 30 or 40 DNS root server IP addresses, but you will not be able to send all of them in one UDP packet (you will have to send them in multiple packets, that will reduce the performance). Hence for performance and low network overhead the root servers are limited to 13 IP addresses.
But yeah in the beginning all of them were located in US. But recent improvements have made them available in different countries and continents. According to Wikipedia, there are more than 370 root servers distributed in different continents.
India had 3 DNS root servers. One in Bangalore, Chennai, and New Delhi.
August: Three root nameservers installed in India:
There are multiple servers for one server for example a.root-servers.net is handled by many servers at different places. You might be thinking how is this being handled with 13 ip addresses.Now there is a technology called as Anycasting that plays a major role in achieving this distributed architecture of DNS root servers. In simple terms anycasting is a technology that makes multiple servers,in fact many servers in different locations to share a single IP address. Which means, many servers will be available at that one address. Whenever a request is send to an anycast IP address, then networking routers
will route that request to the nearest server possible. This means if i want to reach f.root-servers.net from India the nearest possible location is Chennai (which is shown in the map), rather than reaching some other location in the world. This is the reason why DNS root servers rely heavily on IP anycasting technology.
Root Server Name Managed By a.root-servers.net VeriSign, Inc. j.root-servers.net VeriSign, Inc. b.root-servers.net University of Southern California c.root-servers.net Cogent Communications d.root-servers.net University of Maryland e.root-servers.net NASA f.root-servers.net Internet Systems Consortium, Inc. g.root-servers.net US Department of Defence h.root-servers.net US Army i.root-servers.net Netnod k.root-servers.net RIPE NCC l.root-servers.net ICANN m.root-servers.net WIDE
There are 12 organizations that handles and manages DNS root servers. It should have been 13 organizations,but Verisign handles 2 DNS root servers ( when i say two servers, never think that they are two physical server instances…two is logical). But yeah as i told there are 13 root servers with 13 different IP addresses.You might think that these IP addresses never change, yeah correct in ideal cases these IP addresses will not change.
However it can be changed without impacting anything, provided you are changing a couple of them (which happened multiple times in the past decade.). As i have previously told every DNS server will have these 13 IP addresses inbuilt into them, so they can run without any problem even though the new IP address is not updated (because the
change of ip address will only happen to hardly one among them, which can be manually updated by you, or will get updated in the next release cycle of your DNS server software).
DNS root server’s has a DNS root zone file. This DNS root zone file contains the names and IP addresses of all TLD’s.Now TLD stands for Top level Domain. Which are some of the well know names that we know and use in our day to day lives. Some of the common TLD’s are COM, NET, ORG, MIL, GOV, EDU etc.
ROOT ZONE DATABASE:
If you interested in having a look at DNS root zone file, that contains all the DNS servers responsible for all TLD’s like COM, ORG, EDU etc, then you can have a look at the below link, which contains the latest root zone file updates.The below shown zone file is a sample zone file of a.root-servers.net server, from verisign.
What is DNS Query:
There are mainly three types of DNS Queries.
1) Recursive Query 2) Iterative Query 3) Inverse Query.
Two terms are often referred related with DNS (Domain Name System) Queries; Recursion and Iteration.
Recursion A recursive query is a kind of query, in which the DNS server, who received your query will do all the job of fetching the answer, and giving it back to you. During this process, the DNS server might also query other DNS server’s in the internet on your behalf, for the answer.
Iteration is the process of a DNS Client, making repeated DNS (Domain Name System) Queries to different DNS Servers for name resolution.
In the example shown in Figure 5.4, a client somewhere on the Internet needs the IP address of noam.reskit.com. The following events take place:
- The client contacts NameServer1 with a recursive query for noam.reskit.com. The server must now return either the answer or an error message.
- NameServer1 checks its cache and zones for the answer, but does not find it, so it contacts a server authoritative for the Internet (that is, a root server ) with an iterative query for noam.reskit.com.
- The server at the root of the Internet does not know the answer, so it responds with a referral to a server authoritative for the .com domain.
- NameServer1 contacts a server authoritative for the .com domain with an iterative query for noam.reskit.com.
- The server authoritative for the .com domain does not know the exact answer, so it responds with a referral to a server authoritative for the reskit.com domain.
- NameServer1 contacts the server authoritative for the reskit.com domain with an iterative query for noam.reskit.com.
- The server authoritative for the reskit.com domain does know the answer. It responds with the requested IP address.
- NameServer1 responds to the client query with the IP address for noam.reskit.com.
Zone Files and Records:
A zone file is a simple text file that contains the mappings between domain names and IP addresses. This is how the DNS system finally finds out which IP address should be contacted when a user requests a certain domain name.Zone files reside in name servers and generally define the resources available under a specific domain, or the place that one can go to get that information.
Within a zone file, records are kept. In its simplest form, a record is basically a single mapping between a resource and a name. These can map a domain name to an IP address, define the name servers for the domain, define the mail servers for the domain, etc.
$ORIGIN is a parameter equal to the zone’s highest level of authority by default.So if a zone file is used to configure the “example.com.” domain, the
$ORIGIN would be set to
This is either configured at the top of the zone file or it can be defined in the DNS server’s configuration file that references the zone file. Either way, this parameter describes what the zone is going to be authoritative for.
$TTL configures the “time to live” of the information it provides. It is basically a timer. A caching name server can use previously queried results to answer questions until the TTL value runs out.
The DNS zone file consists of directives and resource records.
Directives begin with a $. There are three Directives
- $TTL – Time to Live value for the zone.
- $ORIGIN – Defines base name -used in domain name substitution
- $INCLUDE– Include a file
The $TTL directive must appear at the top of the Zone File before the SOA record.
The SOA (start of authority) must be present in a zone file, and defines the domain global values mainly to do with zone transfer.
TTL stands for Time To Live, which mentions the time in seconds for which caching name servers can cache the data. Here the TTL value mentioned in the beginning of the file, is the bind’s method of specifying the default TTL value for the domain, if not explicitly mentioned.
rupin@L687:~$ dig google.com
;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 273 IN A 188.8.131.52
In the above example, the TTL value of 273 mentioned in the second column of the output is the number of seconds remaining for the TTL to expire. Please note the fact that, the above reply is given by your local name server which you have in your resolv.conf file. 273 seconds means, that after 273 seconds, your local DNS server will follow the entire procedure of fetching A record for google.com(from root to TLD and TLD to authoritative name server of Google.).
But until that TTL expires, your local DNS server will sit and serve the cached records to all the clients. So if you repeatedly do a dig for google.com, you will always get a different value in TTL field(because its in seconds and goes on reducing).
If you really want to know the TTL of any record of any domain, you either need to do a dig to the authoritative name server for that domain, or do a dig + trace for that domain. So let’s find out the exact TTL value for Google.com by doing a dig against its authoritative name server(which you will get by doing a dig NS google.com or a dig + trace)
rupin@L687:~$ dig @ns1.google.com google.com
;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 300 IN A 184.108.40.206
So you will always get the TTL value of 300, when you do a dig by using ns1.google.com. Doing @<server> while using dig will ask dig to send the DNS query to that server, instead of your local DNS server mentioned in resolv.conf.
There are two things that you need to consider about TTL value.
- A low TTL value means, that your authoritative name server will get a higher number of queries, because the TTL gets expired fast, due to which resolvers, and DNS servers will query the server more often. But yeah if you change the records too often, then its advisable to keep a low TTL value, so that the latest entry gets updated fast. So for example you have a website http://www.example.com with an A record (we will be discussing A records in some time)of 172.16.140.43, and you want to change the IP address to something else, then in that case if you have a higher TTL value, the resolvers and DNS server’s who already have the old entry will not refetch the current data until the TTL expires. So if you change records more often its advisable to keep a low value of TTL.
- Keeping a higher value TTL will result in less number of queries hitting your authoritative name server. This is because once a record is cached in a local name server, it will not refetch the value until the TTL expires, and a high value TTL means less number of query, which intern means less load on your authoritative name server.
If you remember the dig + trace we did, the reply from TLD name servers always had a higher TTL value. Which means the servers which gives you the address of authoritative name server for a domain, has a higher value TTL. The default value of that TTL most of the times is 48 hours(2 days). The below shown snippet from the dig + trace shows the TTL value given by gTLD servers.
IN NS a.ianaservers.net.
IN NS b.ianaservers.net.
172800 seconds in the above shown result means 48 hours. That large value is correct, because its very less often that people change the authoritative name server IP addresses(note the fact that the above output is the data given by a.gtld-servers.net showing the name servers for the domain example.com).
SOA or Start of Authority in a Zone file:
SOA is the mandatory record that must be there in all zone files. It specifies the main properties and characteristics of a domain. We will walk through each of them one by one. The default format of specifying a SOA record is shown below.
domain.com. IN SOA ns1.domain.com. admin.domain.com. ( 12083 ; serial number 3h ; refresh interval 30m ; retry interval 3w ; expiry period 1h ; negative TTL )
- domain.com.: This is the root of the zone. This specifies that the zone file is for the
domain.com.domain. Often, you’ll see this replaced with
@, which is just a placeholder that substitutes the contents of the
$ORIGINvariable we learned about above.
- IN SOA: The “IN” portion means internet (and will be present in many records). The SOA is the indicator that this is a Start of Authority record.
- ns1.domain.com.: This defines the primary master name server for this domain. Name servers can either be master or slaves, and if dynamic DNS is configured one server needs to be a “primary master”, which goes here. If you haven’t configured dynamic DNS, then this is just one of your master name servers.
- admin.domain.com.: This is the email address of the administrator for this zone. The “@” is replaced with a dot in the email address. If the name portion of the email address normally has a dot in it, this is replace with a “\” in this part (email@example.com becomes your\name.domain.com).
- 12083: This is the serial number for the zone file. Every time you edit a zone file, you must increment this number for the zone file to propagate correctly. Slave servers will check if the master server’s serial number for a zone is larger than the one they have on their system. If it is, it requests the new zone file, if not, it continues serving the original file.
- 3h: This is the refresh interval for the zone. This is the amount of time that the slave will wait before polling the master for zone file changes.
- 30m: This is the retry interval for this zone. If the slave cannot connect to the master when the refresh period is up, it will wait this amount of time and retry to poll the master.
- 3w: This is the expiry period. If a slave name server has not been able to contact the master for this amount of time, it no longer returns responses as an authoritative source for this zone.
- 1h: This is the amount of time that the name server will cache a name error if it cannot find the requested name in this file.
A and AAAA Records:
Both of these records map a host to an IP address. The “A” record is used to map a host to an IPv4 IP address, while “AAAA” records are used to map a host to an IPv6 address.
The general format of these records is this:
host IN A IPv4_address host IN AAAA IPv6_address
In most cases, this is where you’ll define your web server as “www”:
www IN A 220.127.116.11
We could have used the “@” to refer to the base domain instead:
@ IN A 18.104.22.168
We also have the option of resolving anything that under this domain that is not defined explicitly to this server too. We can do this with the “*” wild card:
* IN A 22.214.171.124
CNAME records define an alias for canonical name for your server (one defined by an A or AAAA record).
For instance, we could have an A name record defining the “server1” host and then use the “www” as an alias for this host:
server1 IN A 126.96.36.199 www IN CNAME server1
Be aware that these aliases come with some performance losses because they require an additional query to the server. Most of the time, the same result could be achieved by using additional A or AAAA records.
MX records are used to define the mail exchanges that are used for the domain. This helps email messages arrive at your mail server correctly.
Unlike many other record types, mail records generally don’t map a host to something, because they apply to the entire zone. As such, they usually look like this:
IN MX 10 mail.domain.com.
The MX record should generally point to a host defined by an A or AAAA record, and not one defined by a CNAME.
So, let’s say that we have two mail servers. There would have to be records that look something like this:
IN MX 10 mail1.domain.com. IN MX 50 mail2.domain.com. mail1 IN A 188.8.131.52 mail2 IN A 184.108.40.206
In this example, the “mail1” host is the preferred email exchange server.
This record type defines the name servers that are used for this zone.
In general, they look like this:
IN NS ns1.domain.com. IN NS ns2.domain.com.
You should have at least two name servers defined in each zone file in order to operate correctly if there is a problem with one server. Most DNS server software considers a zone file to be invalid if there is only a single name server.
As always, include the mapping for the hosts with A or AAAA records:
IN NS ns1.domain.com. IN NS ns2.domain.com. ns1 IN A 220.127.116.11 ns2 IN A 18.104.22.168
The PTR records are used define a name associated with an IP address. PTR records are the inverse of an A or AAAA record. PTR records are unique in that they begin at the
.arpa root and are delegated to the owners of the IP addresses. The Regional Internet Registries (RIRs) manage the IP address delegation to organization and service providers. The Regional Internet Registries include APNIC, ARIN, RIPE NCC, LACNIC, and AFRINIC.
Here is an example of a PTR record for 111.222.333.444 would look like:
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com
This example of a PTR record for an IPv6 address shows the nibble format of the reverse of Google’s IPv6 DNS Server
22.214.171.124.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.126.96.36.199.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.
The command line tool
dig with the
-x flag can be used to look up the reverse DNS name of an IP address.
rupin@L687:~$ dig -x 188.8.131.52 +short
CAA records are used to specify which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for your domain. As of September 8, 2017 all CAs are required to check for these records before issuing a certificate. If no record is present, any CA may issue a certificate. Otherwise, only the specified CAs may issue certificates. CAA records can be applied to single hosts, or entire domains.
An example CAA record follows:
example.com. IN CAA 0 issue "letsencrypt.org"
IN, and record type (
CAA) are common DNS fields. The CAA-specific information above is the
0 issue "letsencrypt.org" portion. It is made up of three parts: flags (
0), tags (
issue), and values (
You may use
dig to fetch CAA records using the following options:
dig example.com type257
Type of DNS Server in Linux:
=> Master (a.k.a. Primary) DNS Server & Slave (a.k.a Secondary) DNS Server.
=> Caching (a.k.a. hint) DNS Server.
=> Forwarding (a.k.a Proxy, Client, Remote) DNS Server.
=> Stealth (a.k.a. DMZ or Hidden Master) DNS Server.
=> Authoritative Only DNS Server.
=> Split Horizon DNS Server.