Difference between revisions of "DNS"

From CNM Wiki
Jump to: navigation, search
(→‎Host servers)
 
(281 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
[[DNS]] is the acronym for [[Domain Name System]]. On the [[Internet]], ''DNS'' stores both [[host name]]s and [[IP address]]es together for the purpose of mapping any [[host name]] to one or more [[IP address]]es or, vice versa, mapping an [[IP address]]es to its [[host name]].
+
[[DNS]] is the acronym for [[Domain Name System]], which is a hierarchical and decentralized domain name system that was originally created to link human-recognizable [[domain name]]s to machine-processed [[Internet protocol address]]es ([[IP address]]es), and later came to be used to determine other data of these names and addresses.
  
−
For instance, a user may request its [[web browser]] to display some [[website]], while providing this [[web browser|browser]] with some [[host name|domain name]]. ''DNS'' is responsible for locating the sought [[website]] in the [[Internet]] and granting the user's [[web browser]] with the right [[IP address]].  
+
Originally created for name mapping, ''DNS'' today also defines technical settings for its core mapping service. In addition, ''DNS'' is used to set up functionality for the [[email]]s using [[DNS record]] such as [[MX record|MX]] and [[TXT record]]s. For example, a public key to sign mail can be added to text records.
  
 +
[[DNS record]]s are contained in so-called [[DNS zone]]s, which [[Internet service provider]]s ([[Internet service provider|ISP]]s) store.
  
−
==Host device aliases==
 
−
:''Main wikipage: [[Host name]]''
 
  
−
Computer networks usually assign those computing devices that are connected to that network some numerical addresses. However, these addresses are rarely convenient for human being to use.
+
==Functionality==
  
−
''DNS'' has been created in order to help human beings to identify a particular computer, called a host, in a network, most notably, on the [[Internet]], using some names that those human beings can recognize. ''DNS'' supplements a numerical address such as <code>176.056.230.964</code> of the host device with some human-readable, human-recognizable [[host name|domain name]] such as <code>wiki.friendsofcnm.org</code> that may contain not necessarily just digits and computer symbols, but also letters, words, or some combinations of those.
+
===Name mapping===
 +
:First of all, ''DNS'' is a hierarchical and decentralized system that maps human-readable names, called [[hostname]]s, and digital addresses such as [[IP address]]es of the resources connected to a network such as the [[Internet]].
 +
 +
:On the [[Internet]], ''DNS'' stores both [[hostname]]s and [[IP address]]es together for the purpose of mapping any [[hostname]] to one or more [[IP address]]es or, vice versa, mapping an [[IP address]]es to its [[hostname]].
  
−
===Domain names===
+
:For instance, a user may request its [[web browser]] to display some [[website]], while providing this [[web browser|browser]] with some [[hostname]] (also known as [[hostname|domain name]]). ''DNS'' is responsible for locating the sought [[website]] in the [[World Wide Web]] and granting the user's [[web browser]] with the right [[IP address]].
−
:On the [[Internet]], a [[host name]] is a human readable label or alias that is assigned to a particular [[IP address]]. This label is used to identify the [[IP address]] of the needed device in various forms of electronic communication, such as the [[World Wide Web]]. Lately, a [[host name]] is often called a [[host name|domain name]]; these two terms can be used interchangeably. The [[host name]] is the central part of any [[URL]].
+
 
 +
:To decentralize, ''DNS'' designates [[authoritative nameserver]]s for each host or host device connected to the network. This structure provides distributed and fault-tolerant service and was designed to avoid a single large central database.
 +
 
 +
===Naming arrangements===
 +
:In addition to name mapping, ''DNS'' defines the [[DNS protocol]], which is the model of the data structures and communication exchanges including [[TTL]]s that are used to propagate [[DNS record]]s through the system.
 +
 
 +
===Email and text functions===
 +
:Finally, ''DNS'' is used to set up properties for:
 +
:*[[mail exchanger|SMTP mail exchanger]]s using [[MX record|MX]] and other [[DNS record]]s. ''DNS'' may be particularly useful in combating unsolicited email messages known as spam by storing a real-time blackhole list (RBL);
 +
:*Human-readable texts about the resource and/or machine-readable data using [[TXT record]]s. This data can be used for verification of domain ownership, email owner verification, and much more.
 +
 
 +
==Hostnames==
 +
:''Main wikipage: [[Hostname]]''
 +
 
 +
On the [[Internet]], a [[hostname]] is a human-readable alias that is assigned to a particular [[IP address]]. This alias is used to identify the [[IP address]] of the needed device in various forms of electronic communication, such as the [[World Wide Web]] and [[email]]s. Earlier, a [[hostname]] was often called a [[hostname|domain name]]; these two terms can be used interchangeably. The [[hostname]] is the central part of any [[URL]].
 +
 
 +
===Purpose===
 +
:Computer networks usually assign those computing devices that are connected to that network some numerical addresses. However, these addresses are rarely convenient for human being to use.
 +
 
 +
:''DNS'' has been created in order to help human beings to identify a particular computer, called a host device or, simply, host, in a network, most notably, on the [[Internet]], using some names that those human beings can recognize. ''DNS'' supplements a numerical address such as <code>176.056.230.964</code> of the host device with some human-readable, human-recognizable [[hostname]] (also known as [[hostname|domain name]]) such as <code>wiki.cnmcyber.com</code> that may contain not necessarily just digits and computer symbols, but also letters, words, or some combinations of those.
  
 
===Right-to-left label hierarchy===
 
===Right-to-left label hierarchy===
−
:Every [[host name|domain name]] consists of two or more labels separated by dots. Those labels are ranged hierarchically from right to left. Each label on the left is classified as a subdomain of the label to its right. For instance, in the [[host name|domain name]], <code>wiki.friendsofcnm.org</code>:
+
:Every [[hostname]] consists of two or more labels separated by dots. Those labels are ranged hierarchically from right to left. Each label on the left is classified as a subdomain of the label to its right. For instance, in the [[hostname]], <code>wiki.cnmcyber.com</code>:
 
:{|class="wikitable" width=100% style="text-align:center;"
 
:{|class="wikitable" width=100% style="text-align:center;"
 
!Domain&nbsp;name
 
!Domain&nbsp;name
−
|style="background-color:#fff;"|<code>'''wiki'''</code>||style="background-color:#fff;"|'''.'''||style="background-color:#fff;"|<code>'''friendsofcnm'''</code>||style="background-color:#fff;"|'''.'''||style="background-color:#fff;"|<code>'''org'''</code>
+
|style="background-color:#fff;"|<code>'''wiki'''</code>||style="background-color:#fff;"|'''.'''||style="background-color:#fff;"|<code>'''cnmcyber'''</code>||style="background-color:#fff;"|'''.'''||style="background-color:#fff;"|<code>'''com'''</code>
 
|-
 
|-
 
!Description
 
!Description
−
|The label for the third level domain, which could also be defined as the second level subdomain.||rowspan="3"|Separator (a&nbsp;dot)||The label for the second level domain or, in other words, the TLD subdomain.||rowspan="3"|Separator (a&nbsp;dot)||The label for the top level domain (TLD)
+
|The label for the third level domain, which could also be defined as the second level subdomain.||rowspan="3"|Separator (a&nbsp;dot)||The label for the second level domain or, in other words, the TLD subdomain.||rowspan="3"|Separator (a&nbsp;dot)||The label for the [[TLD|top level domain]] ([[TLD]])
 
|-
 
|-
 
!Directing&#8209;to&nbsp;server
 
!Directing&#8209;to&nbsp;server
Line 31: Line 52:
  
 
===Name requirements===
 
===Name requirements===
−
:Technically, there is no limit on the number of the levels; however, there are some other restrictions. According to the DoD Host Table Specification, in order to be able to serve as a [[host name]], some combination of labels shall be associated with one or more [[IP address]]es and comply with the following rules:
+
:Technically, there is no limit on the number of the levels; however, there are some other restrictions. According to the DoD Host Table Specification, in order to be able to serve as a [[hostname]], some combination of labels shall be associated with one or more [[IP address]]es and comply with the following rules:
−
:*A [[host name]] must be a text string consisting of only the letters A through Z (upper or lower case), digits 0 through 9, the minus sign (-), and the period (.);
+
:*A [[hostname]] must be a text string consisting of only the letters A through Z (upper or lower case), digits 0 through 9, the minus sign (-), and the period (.);
−
:*No [[host name]] can contain any spaces;
+
:*No [[hostname]] can contain any spaces;
 
:*The first character must be an alphabetic character or a digit;
 
:*The first character must be an alphabetic character or a digit;
 
:*The last character cannot be a minus sign or a period;
 
:*The last character cannot be a minus sign or a period;
−
:*The recommended length for a [[host name]] is up to 24 characters.
+
:*The recommended length for a [[hostname]] is up to 24 characters.
−
:If the [[host name|domain name]] is completely specified, including a top-level domain of the Internet, then the [[host name]] is said to be a [[host name|fully qualified domain name]] ([[host name|FQDN]]).
+
:If the [[hostname]] is completely specified, including a top-level domain of the Internet, then the [[hostname]] is said to be a [[fully qualified domain name]] ([[fully qualified domain name|FQDN]]).
 +
 
 +
===Registrars and resellers===
 +
:[[Hostname]]s are registered by special entities called registrars. These registrars usually create initial [[DNS record]]s as well. Those registrars may also hire other entities called hostname resellers to sell the registration services. Some registrars and all known resellers are also [[Internet service provider]]s ([[Internet service provider|ISP]]s).
 +
 
 +
===Internet service providers===
 +
:''Main wikipage: [[Internet service provider]]''
 +
 
 +
:Any [[Internet service provider]], which is also known by its acronym, [[Internet service provider|ISP]], is a [[legal entity]] that provides Internet services such as Internet access, Internet transit, hostname registration, web hosting, Usenet service, and colocation.
  
 
==Delivery scheme==
 
==Delivery scheme==
Line 64: Line 93:
 
===Geocast===
 
===Geocast===
 
:Geocast is a delivery scheme that routes transfer from one source address to a group of destination addresses based on geographic location.
 
:Geocast is a delivery scheme that routes transfer from one source address to a group of destination addresses based on geographic location.
 +
 +
==System structure==
 +
 +
===Domain levels===
 +
:The ''DNS'' hierarchy is built of three levels:
 +
:#The '''root domains''' are responsible for locating [[TLD nameserver]]s;
 +
:#The '''[[TLD|top level domain]]s''' ([[TLD]]s) are responsible for locating [[host nameserver]]s;
 +
:#The '''host domain'''s are responsible for any [[DNS record]]s beyond [[TLD]].
 +
 +
===Infrastructure===
 +
:''Main wikipage: [[DNS infrastructure]]''
 +
 +
:[[DNS infrastructure]] is designed in a distributed manner. The infrastructure consists of four actors -- [[DNS resolver]]s, [[root nameserver]]s, [[TLD nameserver]]s, and [[host nameserver]]s -- that accommodate the process from entering a human readable [[hostname]] into a [[web browser]] to pointing this [[web browser]] to the exact [[IP address]].
 +
 +
===Resolvers===
 +
:''Main wikipage: [[DNS resolver]]''
 +
 +
:[[DNS resolver]]s moderate any process of translating (resolving) human readable [[hostname]]s into [[IP address]]es that are used in communication between Internet hosts. [[DNS resolver]]s receive requests in the form of a [[hostname]] from a [[web browser]] and request the needed data from [[root nameserver]]s, which are the highest in the hierarchy, if [[DNS resolver]]s haven't already cached that data. Indeed, [[DNS resolver]]s not only redirect requests, but also cache the data needed to identify [[IP address]]es.
 +
 +
==Protocol==
 +
Any [[DNS protocol]] is the model of the data structures and communication exchanges including [[TTL]]s that are used to propagate [[DNS record]]s through the system. The traditional [[DNS protocol]] doesn't address security challenges. The security-sensitive protocol is [[DNSSEC]].
 +
 +
===Non-secured mapping===
 +
:The complete name-to-IP-address process can be described in the following way:
 +
:#When the user enters a [[hostname]] into a [[web browser]], this browser queries their [[Internet service provider]]'s ([[Internet service provider|ISP]]'s) [[DNS resolver]] asking for the [[IP address]].
 +
:#The [[DNS resolver]] asks the [[root nameserver]] where it can find details for that [[hostname]], unless the resolver already has its [[IP address]] data cached.
 +
:#If it is asked, the [[root nameserver]] responds what [[TLD nameserver]] handles this data.
 +
:#The [[DNS resolver]] asks the [[TDL nameserver]] where it can find details for the entered [[hostname]], unless it already has the data cached.
 +
:#If it is asked, the [[TLD nameserver]] responds that this data can be found at the [[host nameserver]]s.
 +
:#The [[DNS resolver]] asks the [[host nameserver]]s where it can find details for the needed [[IP address]], unless it already has the data cached.
 +
:#If it is asked, the [[host nameserver]]s have this data and respond with a [[DNS record]] containing the [[IP address]] for the entered [[hostname]].
 +
:#The ISP's [[DNS resolver]] sends the identified data back to the [[web browser]]. The name-to-IP-address process has been accomplished. Based on its results, the [[web browser]] points its request to the exact [[IP address]] in order to establish communication between this browser and that domain.
 +
 +
===Data structures===
 +
 +
===Communication exchanges===
  
 
==Servers==
 
==Servers==
Line 72: Line 137:
 
===Roles===
 
===Roles===
 
:Different [[nameserver]]s are responsible for different operations and play different roles:
 
:Different [[nameserver]]s are responsible for different operations and play different roles:
−
:*[[DNS resolver]]s moderate any process of translating (resolving) human readable [[host name]]s into [[IP address]]es that are used in communication between Internet hosts. [[DNS resolver]]s cache some data and request the data that they haven't cached from other servers.
+
:*[[DNS resolver]]s moderate any process of translating (resolving) human readable [[hostname]]s into [[IP address]]es that are used in communication between Internet hosts. [[DNS resolver]]s cache some data and request the data that they haven't cached from other servers.
 
:*[[Root nameserver]]s redirect requests to [[TLD nameserver]]s based on the data for [[TLD nameserver]]s that [[root nameserver]]s handle;
 
:*[[Root nameserver]]s redirect requests to [[TLD nameserver]]s based on the data for [[TLD nameserver]]s that [[root nameserver]]s handle;
 
:*[[TLD nameserver]]s redirect requests to [[host nameserver]]s based on the data for [[host nameserver]]s that [[TLD nameserver]]s handle.  
 
:*[[TLD nameserver]]s redirect requests to [[host nameserver]]s based on the data for [[host nameserver]]s that [[TLD nameserver]]s handle.  
Line 79: Line 144:
 
===Functions===
 
===Functions===
 
:With regard to their functions, [[nameserver]]s can be divided in several types; however, one [[nameserver]] can perform several functions:
 
:With regard to their functions, [[nameserver]]s can be divided in several types; however, one [[nameserver]] can perform several functions:
−
:{|class="wikitable" width=100% style="text-align:center;"
+
:*[[Authoritative nameserver]] is any [[nameserver]] that provides its [[DNS zone]] with definitive DNS name resolution based on the data that is stored within the nameserver. These nameservers can be [[primary nameserver]]s (alternatively known as "[[primary nameserver|master nameserver]]s") or [[secondary nameserver]]s (or "[[secondary nameserver|slave nameserver]]s").
−
|[[Nameserver]]
+
:*[[Recursive nameserver]] is any [[nameserver]] that provides DNS name resolution based on its requests to [[authoritative nameserver]]s. Alternatively known as "[[Recursive nameserver|DNS cache]]", "[[Recursive nameserver|caching-only nameserver]]".
−
!Description
 
−
|-
 
−
!Authoritative
 
−
|Provides its [[DNS zone]] with definitive DNS name resolution based on the data that is stored within the nameserver. These nameservers can be primary nameservers (alternatively known as "master nameservers") or secondary (or "slave nameservers")
 
−
|-
 
−
!Recursive
 
−
|Provides DNS name resolution based on requests to authoritative nameservers. Alternatively known as "DNS cache", "caching-only nameserver"
 
−
|}
 
  
 
===Zones===
 
===Zones===
Line 105: Line 162:
 
|-
 
|-
 
![[DNS zone|Host&nbsp;DNS]]
 
![[DNS zone|Host&nbsp;DNS]]
−
|All the data related to a particular host, usually in a file. Because users can commonly access and host administrators can administer only that data, [[DNS zone]] commonly refers to this type of areas||[[Host nameserver|Host&nbsp;NS]]
+
|All the data related to a particular host, usually in a structured text file that is called the zone file, but other database systems are common as well. Because users can commonly access and host administrators can administer only that data, [[DNS zone]] commonly refers to this type of areas||[[Host nameserver|Host&nbsp;NS]]
 
|}
 
|}
  
−
==DNS infrastructure==
+
===BIND (NS software)===
−
:''Main wikipage: [[DNS infrastructure]]''
+
:As there are a large number of different [[nameserver]] software packages, the format of these zone files can vary slightly between different implementations. The most widely-used DNS software on the Internet today is the Berkeley Internet Name Domain (BIND) [[nameserver]].
−
 
 
−
[[DNS infrastructure]] is designed in a distributed manner. The infrastructure consists of four actors -- [[DNS resolver]]s, [[root nameserver]]s, [[TLD nameserver]]s, and [[host nameserver]]s -- that accommodate the process from entering a human readable [[host name|domain name]] into a [[web browser]] to pointing this [[web browser]] to the exact [[IP address]].
 
  
−
===Resolvers===
+
:Originally written in 1984 by four Berkeley College students as a graduate project, the BIND [[nameserver]] was eventually rewritten in 2000 with contributions coming from a number of large organizations including IBM, Hewlett Packard, Compaq, and Sun Microsystems.
−
:''Main wikipage: [[DNS resolver]]''
 
  
−
:[[DNS resolver]]s moderate any process of translating (resolving) human readable [[host name]]s into [[IP address]]es that are used in communication between Internet hosts. [[DNS resolver]]s receive requests in the form of a [[host name]] from a [[web browser]] and request the needed data from [[root nameserver]]s, which are the highest in the hierarchy, if [[DNS resolver]]s haven't already cached that data. Indeed, [[DNS resolver]]s not only redirect requests, but also cache the data needed to identify [[IP address]]es.
+
:This rewrite was labeled version 9 and is currently still the supported version of the BIND [[nameserver]] in use on systems around the world (and also used by the majority of DNS [[root nameserver]]s themselves). Below is an example of a zone file for the BIND 9 [[nameserver]]:<blockquote><code>~<br>$TTL 14400<br>$ORIGIN example.com.<br>@ 14400 IN SOA ns1.example.com.  admin.example.com. (<br>&nbsp;&nbsp;&nbsp;2012121902 ;<br>&nbsp;&nbsp;&nbsp;3600; refresh seconds<br>&nbsp;&nbsp;&nbsp;600; retry<br>&nbsp;&nbsp;&nbsp;86400; expire<br>&nbsp;&nbsp;&nbsp;3600; minimum<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;);<br>IN A 12.34.56.78<br>IN NS ns1.example.com.<br>IN NS ns2.example.com.<br>ns1 IN A 11.11.11.11<br>ns2 IN A 22.22.22.22<br>www IN CNAME example.com.<br>ftp IN CNAME example.com.<br>mail IN MX 10 example.com.<br>DNS zone file example (BIND [[nameserver]])</code></blockquote>
−
 
 
−
:The complete name-to-IP-address process can be described in the following way:
 
−
:#When the user enters a [[host name|domain name]] into a [[web browser]], this browser queries their Internet Service Provider's (ISP) [[DNS resolver]] asking for the [[IP address]].
 
−
:#The [[DNS resolver]] asks the [[root nameserver]] where it can find details for that [[host name|domain name]], unless the resolver already has its [[IP address]] data cached.
 
−
:#If it is asked, the [[root nameserver]] responds what [[TLD nameserver]] handles this data.
 
−
:#The [[DNS resolver]] asks the [[TDL nameserver]] where it can find details for the entered [[host name|domain name]], unless it already has the data cached.
 
−
:#If it is asked, the [[TLD nameserver]] responds that this data can be found at the [[host nameserver]]s.
 
−
:#The [[DNS resolver]] asks the [[host nameserver]]s where it can find details for the needed [[IP address]], unless it already has the data cached.
 
−
:#If it is asked, the [[host nameserver]]s have this data and respond with a [[DNS record]] containing the [[IP address]] for the entered [[host name|domain name]].
 
−
:#The ISP's [[DNS resolver]] sends the identified data back to the [[web browser]]. The name-to-IP-address process has been accomplished. Based on its results, the [[web browser]] points its request to the exact [[IP address]] in order to establish communication between this browser and that domain.
 
  
 +
==Domain level servers==
 
===Root servers===
 
===Root servers===
 
:''Main wikipage: [[Root nameserver]]''
 
:''Main wikipage: [[Root nameserver]]''
  
−
:[[Root nameserver]]s are responsible for the initial delegation of requests received from [[DNS resolver]]s to the correct [[TLD nameserver]]s. The [[DNS root zone]] defines 13 [[host name]]s for [[root nameserver]]s, every of which starts with a letter from <code>a</code> to <code>m</code> and ends in <code>.root-servers.net</code>. The letters are assigned to different organizations called ''operators''; however, [[Verisign]] currently manages both <code>a</code> and <code>j</code>:
+
:[[Root nameserver]]s are responsible for the initial delegation of requests received from [[DNS resolver]]s to the correct [[TLD nameserver]]s. The [[DNS root zone]] defines 13 [[hostname]]s for [[root nameserver]]s, every of which starts with a letter from <code>a</code> to <code>m</code> and ends in <code>.root-servers.net</code>. The letters are assigned to different organizations called ''operators''; however, [[Verisign]] currently manages both <code>a</code> and <code>j</code>:
 
:{|class="wikitable" width=100% style="text-align:center;"
 
:{|class="wikitable" width=100% style="text-align:center;"
 
|Letter
 
|Letter
Line 176: Line 221:
 
|}
 
|}
  
−
:13 [[host name]]s of [[root nameserver]]s, but a majority of the [[IP address]]es assigned to the [[root nameserver]] are [[anycast]] addresses. For instance, <code>l.root-servers.net</code>, which [[ICANN]] manages, is a cluster of over 130 physical servers that have the same [[IP address]], but distributed around the globe.
+
:13 [[hostname]]s of [[root nameserver]]s, but a majority of the [[IP address]]es assigned to the [[root nameserver]] are [[anycast]] addresses. For instance, <code>l.root-servers.net</code>, which [[ICANN]] manages, is a cluster of over 130 physical servers that have the same [[IP address]], but distributed around the globe.
  
 
:The [[United States Department of Commerce]] controls the [[DNS root zone]]. This department delegated its management to the Internet Assigned Numbers Authority (IANA). The IANA has hired the [[ICANN|Internet Corporation for Assigned Names and Numbers]] ([[ICANN]]) to manage [[DNS root zone]], but the [[United States Department of Commerce]] still needs to approve any changes proposed for the [[DNS root zone]].
 
:The [[United States Department of Commerce]] controls the [[DNS root zone]]. This department delegated its management to the Internet Assigned Numbers Authority (IANA). The IANA has hired the [[ICANN|Internet Corporation for Assigned Names and Numbers]] ([[ICANN]]) to manage [[DNS root zone]], but the [[United States Department of Commerce]] still needs to approve any changes proposed for the [[DNS root zone]].
Line 188: Line 233:
 
:''Main wikipage: [[Host nameserver]]''
 
:''Main wikipage: [[Host nameserver]]''
  
−
:The configured [[host nameserver]]s handle [[DNS record]]s such as [[host name]] (also known as [[host name|domain name]]), [[IP address]], [[host name]] aliases, mail server details, for a particular host device. The ''configured'' means that someone needs to configure its [[DNS zone]], which are usually bundled into one zone file. The zone file contains [[DNS record]]s of all domains for which the given [[nameserver]] is authoritative.
+
:The configured [[host nameserver]]s handle [[DNS record]]s such as [[hostname]] (also known as [[hostname|domain name]]), [[IP address]], [[hostname]] aliases, [[mail server]] details, for a particular host device. The ''configured'' means that someone needs to configure its [[DNS zone]], which are usually bundled into one zone file. The zone file contains [[DNS record]]s of all domains for which the given [[nameserver]] is [[authoritative nameserver|authoritative]].
  
−
:Host name resellers usually provide host name buyers with default files that often list an [[A record]] and [[NS record]]s, but owners of host names can alternate almost any [[DNS record]] for their host. The [[SOA record]] is the exception; only host name resellers can alternate that.
+
:Hostname registrars usually provide hostname buyers with default files that often list an [[A record]] and [[NS record]]s, but owners of [[hostname]]s can alternate almost any [[DNS record]] for their host. The [[SOA record]] is the exception; rarely, hostname registrars allow hostname buyers alternating that.
  
 
==Requests==
 
==Requests==
Line 197: Line 242:
  
 
===Directions===
 
===Directions===
−
:#A '''forward request''' is a [[DNS request]] made in order to obtain the [[IP address]] based on its [[host name]].
+
:#A '''forward request''' is a [[DNS request]] made in order to obtain the [[IP address]] based on its [[hostname]].
−
:#A '''reverse request''' is a [[DNS request]] made in order to obtain the [[host name]] based on its [[IP address]].
+
:#A '''reverse request''' is a [[DNS request]] made in order to obtain the [[hostname]] based on its [[IP address]].
  
 
===Ports===
 
===Ports===
Line 213: Line 258:
 
===Non-recursive query===
 
===Non-recursive query===
 
:Any non-recursive query is the [[DNS query]] that the [[nameserver]] resolves, without asking other [[nameserver]]s when the requested server needs more data. In other words, any recursive query expects the partial, but quick answer from the requested server. That server is not supposed to accomplish any research. This [[nameserver]] may resolve that query:
 
:Any non-recursive query is the [[DNS query]] that the [[nameserver]] resolves, without asking other [[nameserver]]s when the requested server needs more data. In other words, any recursive query expects the partial, but quick answer from the requested server. That server is not supposed to accomplish any research. This [[nameserver]] may resolve that query:
−
:*Completely if this nameserver is authoritative and responsible for the requested zone;
+
:*Completely if this nameserver is [[authoritative nameserver|authoritative]] and responsible for the requested zone;
 
:*Probably if this nameserver and/or the requesting [[DNS resolver]] has some cached data;
 
:*Probably if this nameserver and/or the requesting [[DNS resolver]] has some cached data;
 
:*Negatively if neither this nameserver nor the requesting [[DNS resolver]] has any cached data.
 
:*Negatively if neither this nameserver nor the requesting [[DNS resolver]] has any cached data.
  
 
===Iterative query===
 
===Iterative query===
−
:Any iterative query is the [[DNS query]] that the [[DNS resolver]] continues while querying one or more [[nameserver]]s in chain until the request has been resolved completely by the authoritative server that is responsible for the particular zone.
+
:Any iterative query is the [[DNS query]] that the [[DNS resolver]] continues while querying one or more [[nameserver]]s in chain until the request has been resolved completely by the [[authoritative server]] that is responsible for the particular zone.
  
 
===Method combinations===
 
===Method combinations===
Line 225: Line 270:
 
:Some [[nameserver]]s allows for working using different methods or combinations of methods in different segments. This feature is called "view" in [[BIND]]. For instance, local [[IP address]]es such as 10.0.0.0/8 can receive local addresses of host devices, while [[DNS request]]s from the outside of the network would be resolved using external addresses;
 
:Some [[nameserver]]s allows for working using different methods or combinations of methods in different segments. This feature is called "view" in [[BIND]]. For instance, local [[IP address]]es such as 10.0.0.0/8 can receive local addresses of host devices, while [[DNS request]]s from the outside of the network would be resolved using external addresses;
  
−
:A [[nameserver]] may also be authoritative for a particular zone for a particular range of [[IP address]]es. For example, the server located at 10.0.0.0/8 announces itself authoritative for the internal zone; so, any request from the external servers to get data on the internal zone would be resolved as "unknown."
+
:A [[nameserver]] may also be [[authoritative nameserver|authoritative]] for a particular zone for a particular range of [[IP address]]es. For example, the server located at 10.0.0.0/8 announces itself [[authoritative nameserver|authoritative]] for the internal zone; so, any request from the external servers to get data on the internal zone would be resolved as "unknown."
  
 
==Records==
 
==Records==
−
Any [[DNS record]] (officially known as [[resource record]] or [[RR]]) is a critical property assigned to a [[host name]]. Each [[DNS record]] is stored in a zone file. While being initially created as a name-to-IP address mapping database, ''DNS'' also allows for more details that [[DNS record]]s provide. They may include email addresses, aliases, anti-spam data, and other data.  
+
:''Main wikipage: [[DNS record]]''
 +
 
 +
Any [[DNS record]] (officially known as [[resource record]] or [[RR]]) is a critical property assigned to a [[hostname]]. Each [[DNS record]] is stored in a zone file. While being initially created as a name-to-IP address mapping database, ''DNS'' also allows for more details that [[DNS record]]s provide. They may include email addresses, aliases, anti-spam data, and other data.  
  
 
===SOA record===
 
===SOA record===
−
:The [[SOA record]] is a mandatory [[DNS record]] for any [[DNS zone]] that states that this particular [[nameserver]] is the authoritative server for the requested [[host name]]. ''SOA'' stands for ''Start Of Authority''. An example record is as follows:<blockquote><code>@ 14400 IN SOA ns1.friendsofcnm.org. admin.friendsofcnm.org. (<br>&nbsp;2013022001; serial number<br>&nbsp;86400; refresh seconds<br>&nbsp;600; retry seconds<br>&nbsp;86400; expire seconds<br>&nbsp;3600; minimum TTL seconds&nbsp;);</code></blockquote>
+
:''Main wikipage: [[SOA record]]''
 +
 
 +
:The [[SOA record]] is a mandatory [[DNS record]] for any [[DNS zone]] that states that this particular [[nameserver]] is the [[authoritative server]] for the requested [[hostname]]. ''SOA'' stands for ''Start Of Authority''. An example record is as follows:<blockquote><code>cnmcyber.com. 14400 IN SOA ns1.cnmcyber.com. admin.opplet.net. (<br>&nbsp;&nbsp;&nbsp;2019021701; serial number<br>&nbsp;&nbsp;&nbsp;86460; refresh seconds<br>&nbsp;&nbsp;&nbsp;600; retry seconds<br>&nbsp;&nbsp;&nbsp;86400; expire seconds<br>&nbsp;&nbsp;&nbsp;3600; minimum TTL seconds&nbsp;&nbsp;&nbsp;);</code></blockquote>
  
−
:The same record can be written in a shorter form: <code>@ 14400 IN SOA ns1.friendsofcnm.org admin.friendsofcnm.org 2013022001 86400 600 86400 3600</code>, where:
+
:There are many forms of the [[SOA record]]. The same example can be written in a shorter form: <code>@ 14400 IN SOA ns1.cnmcyber.com admin.opplet.net 2019021701 86460 600 86400 3600</code>, where:
 
:{|class="wikitable" width=100%
 
:{|class="wikitable" width=100%
−
!style="text-align:right;"|ns1.friendsofcnm.org
+
!Sample&nbsp;code
−
|The primary [[nameserver]] for the host device.
+
|style="text-align:center;"|Field
 +
!Description!!Values
 
|-
 
|-
−
!style="text-align:right;"|admin.friendsofcnm.org
+
|style="background-color:#fff;"|<code>@</code>
−
|The responsible party for the host.
+
!Current origin
 +
|A free standing "@" encodes the name of the host in which this record is located.||[[Hostname]]
 
|-
 
|-
−
!style="text-align:right;"|2013022001
+
|style="background-color:#fff;"|<code>14400</code>
−
|A timestamp that changes whenever the host is updated.
+
![[TTL]]
 +
|The number of seconds for which the record may be cached by client side programs. If it is set as 0, it indicates that the record should not be cached.||From 0 to 2147483647
 
|-
 
|-
−
!style="text-align:right;"|86400
+
|style="background-color:#fff;"|<code>IN</code>
−
|The number of seconds before the zone should be refreshed.
+
!Class
 +
|The [[Internet]] or [[intranet]]; other options are all outdated.||IN
 
|-
 
|-
−
!style="text-align:right;"|600
+
|style="background-color:#fff;"|<code>SOA</code>
−
|The number of seconds before a failed refresh should be retried.
+
![[DNS record|Record]]
 +
|''SOA'' stands for [[SOA record]] and sets up the start of authority||Stable
 
|-
 
|-
−
!style="text-align:right;"|86400
+
|style="background-color:#fff;"|<code>ns1.cnmcyber.com</code>
−
|The upper limit in seconds before a zone is considered no longer authoritative.
+
![[Nameserver]]
 +
|The [[nameserver]] in which the zone file is located; this is the [[primary nameserver]] for the host device.||Assigned
 
|-
 
|-
−
!style="text-align:right;"|3600
+
|style="background-color:#fff;"|<code>admin.opplet.net</code>
−
|The negative result [[TTL]] (for example, how long a [[DNS resolver]] should consider a negative result for a subdomain to be valid before retrying).
+
![[Email address]]
 +
|The administrative email contact for the [[DNS zone]]. This record indicates the responsible party for the host. The actual email contact in this example is <code>admin@opplet.net</code>. The "." replaces the "@" symbol in [[DNS zone]] because the "@" symbol encodes the current origin.||Vary
 +
|-
 +
|style="background-color:#fff;"|<code>2019021701</code>
 +
!Serial number
 +
|The "serial number" value is created in the YYYYMMDDNN (YYYY for a year, MM for a month, DD for a date, and NN for a sequential number) format for [[version control]]. This control is vital because of the need to configure multiple [[nameserver]]s. The value in the example is made up from the year of 2019, February (month #02), 17th (for a day), and revision number 01. This serial number is a timestamp that changes whenever the host is updated.||Automatic
 +
|-
 +
|style="background-color:#fff;"|<code>86460</code>
 +
!Refresh
 +
|The number of seconds before the zone should be refreshed. This value sets up how long a [[secondary nameserver]] shound wait before checking whether updates have been made on the [[primary nameserver]]. When checking, the [[secondary nameserver]] will check the serial number of the zone on the master server, and if different will request a zone transfer to update its local copy. The same value of the sample can be written as <code>24h1m</code> since 86,460 seconds are equal to 24 hours and one minute.||Usually, from 6 to 24 hours
 +
|-
 +
|style="background-color:#fff;"|<code>600</code>
 +
!Retry
 +
|The number of seconds before a failed refresh should be retried. This value sets up how long a [[secondary nameserver]] will wait to retry a zone transfer in the event the initial attempt fails. This value is not significant.||Usually, a fraction of the ''Refresh''
 +
|-
 +
|style="background-color:#fff;"|<code>86400</code>
 +
!Expire
 +
|The upper limit in seconds before a zone is considered no longer [[authoritative nameserver|authoritative]]. This value sets up how long a [[secondary nameserver]] will continue to attempt a zone transfer before giving up. If this value is reached before a successful zone transfer is made, the [[secondary nameserver]] will expire its local zone file and stop responding to user queries.||Usually, from 14 to 28 days
 +
|-
 +
|style="background-color:#fff;"|<code>3600</code>
 +
!Minimum TTL
 +
|The negative result [[TTL]] (for example, how long a [[DNS resolver]] should consider a negative result for a subdomain to be valid before retrying). This value sets up how long a DNS cache may hold a negative value (e.g. an error message) before requesting fresh copies. In the [[SOA record]], this field is the most important. If your DNS information keeps changing, keep it down to a day or less. Otherwise if your DNS record doesn’t change regularly, step it up between 1 to 5 days. The benefit of keeping this value high, is that your website speeds increase drastically as a result of reduced lookups. Caching servers around the globe would cache your records and this improves site performance.||Depends on the need
 
|}
 
|}
  
 +
===A record===
 +
:''Main wikipage: [[A record]]''
  
−
   
+
:Any [[A record]] is the [[DNS record]] that translates a [[hostname]] into an [[IPv4 address]]. In other words, [[A record]]s set up relationships between:
−
   
+
:#[[Hostname]]s, which are human-friendly names, and
 +
:#[[IPv4 address]]es, which are [[IP address]]es expressed using the [[IPv4]] standard.
  
 +
:A [[PTR record]] can set up the opposite relationship. The sample of the [[A record]] is as follows: <code>cnmcyber.com IN A 159.89.93.1</code>, where:
 +
:{|class="wikitable" width=100%
 +
!Sample&nbsp;code
 +
|style="text-align:center;"|Field
 +
!Description!!Values
 +
|-
 +
|style="background-color:#fff;"|<code>cnmcyber.com</code>
 +
!Labels
 +
|One or more labels of the [[hostname]] and [[TLD]] name.||Selected
 +
|-
 +
|style="background-color:#fff;"|<code>IN</code>
 +
!Class
 +
|The [[Internet]] or [[intranet]]; other options are all outdated.||IN
 +
|-
 +
|style="background-color:#fff;"|<code>A</code>
 +
![[DNS record|Record]]
 +
|''A'' stands for [[A record]] and sets up the relationship between hostname labels and [[IP address]]||Stable
 +
|-
 +
|style="background-color:#fff;"|<code>159.89.93.1</code>
 +
![[IPv4 address]]
 +
|The location that the resulting [[hostname]] points to.||Assigned
 +
|}
  
−
The first entry in the "SOA" record contains the name of the host
+
===AAAA record===
−
where the zone file is located (ns1.example.com above) as well as the
+
:''Main wikipage: [[AAAA record]]''
−
administrative email contact for the DNS zone (admin.example.com
 
−
above — the "@" symbol is replaced with a "." within DNS zone files).
 
−
The "serial number" value is used as a type of version control on the DNS
 
−
records. Where multiple nameservers are configured, ensuring that each
 
−
server"s SOA serial number value is the same is a good indication that
 
−
DNS changes have been replicated on all nameservers.
 
−
The "refresh" value is how long a secondary nameserver will wait before
 
−
checking whether updates have been made on the primary server. When
 
−
checking, the secondary server will check the serial number of the zone
 
−
on the master server, and if different will request a zone transfer to
 
−
update its local copy.
 
−
The "retry" value is how long a secondary nameserver will wait to retry a
 
−
zone transfer in the event the initial attempt fails.
 
−
The "expire" value is how long a secondary nameserver will continue to
 
−
attempt a zone transfer before giving up. If this value is reached before a
 
−
successful zone transfer is made, the secondary nameserver will expire
 
−
its local zone file and stop responding to user queries.
 
−
The "minimum TTL" value is an indication of how long a DNS cache
 
−
may hold a negative value (e.g. an error message) before requesting
 
−
fresh copies.
 
  
−
===A record===
+
:Any [[AAAA record]] is the [[DNS record]] that sets up a relationship between:
−
"A" records are one of the key record types within the DNS. Their purpose
+
:#A [[hostname]], which is a human-friendly name, and
−
is to define a relationship between a human-friendly name and an IPv4
+
:#An [[IPv6 address]], which is an [[IP address]] expressed using the [[IPv6]] standard.
−
address. These records are useful for pointing different portions of your
+
 
−
domain to different IP addresses (e.g. pointing "www.example.com" to
+
:[[AAAA record]]s are similar to [[A record]]s. The only difference is that [[A record]]s point to [[IPv4 address]]es and [[AAAA record]]s do to [[IPv6 address]]es.
−
your web server).
+
 
−
Each DNS "A" record consists of both a host name and IP address. The  
+
===NS record===
−
format of these records is as follows: 
+
:''Main wikipage: [[NS record]]''
−
<NODE NAME> IN A <IP ADDRESS>
 
−
The "node name" value above will be the portion of the address that
 
−
precedes ".example.com" (for example "www"). The IP address is the
 
−
location that the resulting [[host name]] ("www.example.com") will point to.
 
  
−
===AAAA record===
+
:Any [[NS record]] is the [[DNS record]] that specifies [[authoritative nameserver]]s for the [[hostname]]. ''NS'' is the acronym for ''name server''.
  
−
"AAAA" records are similar to DNS "A" records.The only difference is
+
:Each [[NS record]] consists of both the [[hostname]] and nameserver hostname. It can be formatted as follows: <blockquote><code>cnmcyber.com. IN NS ns1.digitalocean.com</code></blockquote>
−
that "AAAA" records point to IPv6 addresses instead of IPv4 addresses.
 
−
Configuration of the record and layout is the same: simply replace "A"
 
−
with "AAAA" and use an IPv6 address.
 
  
−
===NS record===
+
:Two different authorities, hostname registrars or resellers and host owner, can set these records up. Two different values should be configured to match; otherwise, some problems may occur.
−
"NS" records are used to specify what the nameservers for the [[host name|domain name]] are. These should ideally match the values set at the [[host name|domain name]] registrar.
 
−
Each DNS "NS" record consists of both the [[host name|domain name]] and
 
−
nameserver [[host name]] and is formatted as follows:
 
−
example.com. IN NS <HOSTNAME OF NAMESERVER> 
 
−
The [[host name]] will generally be a value such as "ns1.yourdomain.
 
−
com" or "ns1.yourwebhost.com". If these values do not match those
 
−
configured with the [[host name|domain name]] registrar, it can lead to problems  
 
−
accessing your website in certain circumstances.
 
  
 
===CNAME record===
 
===CNAME record===
−
"CNAME" is short for canonical name. These records are used to define
+
:''Main wikipage: [[CNAME record]]''
−
an alias for another domain or [[host name]]. These records are particularly
+
 
−
useful when you have multiple [[host name]]s that are located on the same  
+
:Any [[CNAME record]] is the [[DNS record]] that sets up an alias for another [[hostname]]. ''CNAME'' is an abbreviation for ''canonical name''. Particularly, [[CNAME record]]s are useful when several [[hostname]]s are located on the same [[IP address]]. For instance, <code>www.cnmcyber.com. IN CNAME cnmcyber.com.</code> would point any visitor of <code>www.cnmcyber.com</code> to <code>cnmcyber.com</code> (without <code>www.</code>).
−
IP address.
+
 
−
Each "CNAME" record needs to point to another valid [[host name]], either  
+
:Each [[CNAME record]] shall point to another valid [[hostname]], either within the same domain or even a completely different domain. Preferably, this record shall point to the [[hostname]] that is configured in an [[A record]].
−
for the same domain or even a completely different domain. Generally
 
−
"CNAME" records point to a [[host name]] that is configured in a DNS "A"
 
−
record. The format of these records is as follows: 
 
−
<HOST NAME>  IN CNAME <EXISTING HOSTNAME>
 
−
The [[host name]] is the value preceding the ".example.com" as in the "A"
 
−
record example and is typically something like "www." The existing
 
−
hostname could be another [[host name]] for the current domain, for
 
−
example "blog.example.com." In this case, when a user attempts to visit
 
−
"www.example.com" they will see the content associated with "blog.
 
−
example.com."
 
−
If the existing [[host name]] value is set to a [[host name]] on a different domain 
 
−
— for example "www.domain2.com" — when a user visits "www.example.
 
−
com" they will see the same content as a user visiting "www.example.com."
 
  
 
===MX record===
 
===MX record===
−
"MX" is short for Mail Exchanger. These records are used to identify the  
+
:''Main wikipage: [[MX record]]''
−
server that handles email address for your [[host name|domain name]].
+
 
−
Each "MX" record contains three pieces of information: the [[host name]],  
+
:Any [[MX record]] is the [[DNS record]] that identifies the server that handles email address for the [[hostname]]. ''MX'' is an abbreviation for ''[[mail exchanger]]''.
−
the priority and the mail server"s [[host name]]. The format of an "MX"
+
 
−
record is as follows:
+
:Each [[MX record]] contains three pieces of information: the [[hostname]], the priority, and the [[hostname]] of the [[mail server]] that handles mail for the host device. The sample of the [[MX record]] is as follows: <code>cnmcyber.com IN MX 10 cnmcyber.com</code>, where:
−
<HOSTNAME> IN MX <PRIORITY><MAIL SERVER HOSTNAME>
+
:{|class="wikitable" width=100%
−
The [[host name]] value is the domain for which the MX record exists. This is
+
!Sample&nbsp;code
−
generally set to the value of your [[host name|domain name]] (e.g. "example.com.").
+
|style="text-align:center;"|Field
−
The priority value is a numerical value that signifies the priority of this  
+
!Description!!Values
−
particular MX record — and hence the mail server. The values used for  
+
|-
−
this are only important if you have more than one mail server. The lower  
+
|style="background-color:#fff;"|<code>cnmcyber.com</code>
−
the value of the priority field, the higher the priority of the mail server.
+
!Labels
−
The mail server [[host name]] is then the [[host name]] that handles email for  
+
|One or more labels of the [[hostname]] and [[TLD]] name.||Selected
−
this domain. It could be a google.com address if the domain uses Google  
+
|-
−
Apps for email hosting, but the simplest setup is to have the [[host name]] set
+
|style="background-color:#fff;"|<code>IN</code>
−
to "mail.example.com". If this is the case, it is important to ensure that a  
+
!Class
−
valid DNS "A" record exists for the "mail" [[host name]]. If this isn"t configured
+
|The [[Internet]] or [[intranet]]; other options are all outdated.||IN
−
properly, you may experience issues receiving email at your domain.
+
|-
 +
|style="background-color:#fff;"|<code>MX</code>
 +
![[MX record|Record]]
 +
|''MX'' stands for [[MX record]] and sets up the relationship between hostname labels and [[IP address]]||Stable
 +
|-
 +
|style="background-color:#fff;"|<code>10</code>
 +
!Priority
 +
|A numerical value that signifies the priority of this particular [[MX record]] and, consequently, for the [[mail server]]. The values used for this are only important if more than one [[mail server]] is used. The lower the value of the priority field, the higher the priority of the [[mail server]].||Assigned
 +
|-
 +
|style="background-color:#fff;"|<code>mail.cnmcyber.com</code>
 +
![[Mail server]] hostname
 +
|The [[hostname]] of the [[mail server]] that handles email for this domain. This hostname is a google address when [[Google Apps]] handle emails for this host device. Any [[mail server]] hostname should have a validly configured [[A record]] in order to receive emails smoothly.||Assigned
 +
|}
  
 
===TXT record===
 
===TXT record===
−
"TXT" (or text) records serve multiple purposes. They allow for virtually
+
:''Main wikipage: [[TXT record]]''
−
any free text to be stored and can be assigned to specific [[host name]]s.  
+
 
−
The typical format for a TXT record is as follows:
+
:Any [[TXT record]] is a [[DNS record]] that allows for storage of human-readable and machine-readable texts that, if posted, would be assigned to a specific [[hostname]].
−
<HOSTNAME> IN TXT <TEXT DATA>
+
 
−
  "TXT" records often store sender policy framework (SPF) data . SPF data  
+
:With regard to machine-readable texts, [[TXT record]]s may serve multiple purposes, including:
−
is used to inform email servers which actual systems are authorized  
+
:*[[Sender policy framework]] ([[SPF]]) data storage. This data confirms the actual systems that are authorized to send mail on behalf of the given [[hostname]]. This is useful in the prevention of spam emails being sent with a forged sender address originating from the particular host device. RFC 4408 discourages this practice as "not optimal," however, because SPF now has its own DNS resource record type (code 99);
−
to send mail on behalf of the given [[host name]]. This is useful in the  
+
:*[[DomainKeys Identified Mail]] ([[DKIM]]) data. This data allows a receiving [[mail server]] to authenticate entities that have signed a specific email message. [[DKIM]] is similar to [[SPF]] in that it can help reduce spam email from containing forged email addresses originating from your domain, but it also contains a large amount of additional functionality.
−
prevention of spam emails being sent with a forged sender address  
 
−
originating from your domain. (RFC 4408 discourages this practice  
 
−
as "not optimal," however, because SPF now has its own DNS resource  
 
−
record type (code 99).)
 
−
Another common use of the "TXT" records is for DomainKeys Identified  
 
−
Mail (DKIM) data. These records allow a receiving mail server to  
 
−
authenticate entities that have signed a specific email message. DKIM  
 
−
is similar to SPF in that it can help reduce spam email from containing  
 
−
forged email addresses originating from your domain, but it also  
 
−
contains a large amount of additional functionality.
 
  
 
===PTR record===
 
===PTR record===
−
The "PTR" record type is used to perform the exact opposite
+
:''Main wikipage: [[PTR record]]''
−
functionality of the DNS "A" record. Where the "A" record allows for the
+
 
−
translation of a [[host name]] into an IP address, the "PTR"
+
:Any [[PTR record]] is a [[DNS record]] that translates a [[hostname]] into an [[IP address]]. ''PTR'' is an abbreviation for ''pointer''; [[PTR record]]s ''point'' to [[IP address]]es. In comparison with [[A record]]s, [[PTR record]]s perform the exact opposite function.
−
record allows for an IP address to be translated into a [[host name|domain name]].
+
 
−
The format of a "PTR" record is as follows:
+
:[[PTR record]]s use the following format: <code><IP address in a reverse order>.in-addr.arpa PTR <hostname></code>. For instance, <code>1.93.89.159.in-addr.apra PTR cnmcyber.com</code>, where:
−
<IP REVERSED>.in-addr.arpa PTR <DOMAIN>
+
:{|class="wikitable" width=100%
−
The first field is the IP address in reverse format, with the "in-addr.arpa"
+
!Sample&nbsp;code
−
value appended to the end, for example "1.0.168.192.in-addr.arpa". The  
+
|style="text-align:center;"|Field
−
domain value would then be the [[host name|domain name]] you want the IP address  
+
!Description!!Values
−
(192.168.0.1 in this example) to resolve to.
+
|-
−
Ensuring that both forward lookups (using "A" records) and reverse lookups
+
|style="background-color:#fff;"|<code>1.93.89.159</code>
−
(using "PTR" records) match is important: in some instances, applications
+
!Reversed IP address
−
will not work correctly if this is not configured correctly. For example, some
+
|The [[IP address]] of the location that the resulting [[hostname]] points to in a reverse order. The actual [[IP address]] used in this example is <code>159.89.93.1</code>||Assigned
−
mail servers will not accept mail from a mail server if the reverse lookup
+
|-
−
does not match the [[host name|domain name]] the email is originating from.
+
|style="background-color:#fff;"|<code>.in-addr.arpa</code>
 +
!Domain
 +
|The domain name that historically arrived from the times when the Internet was called ''Arpa''. ''In-addr'' is an abbreviation for ''internet address''.||No other options
 +
|-
 +
|style="background-color:#fff;"|<code>PTR</code>
 +
![[PTR record|Record]]
 +
|''PTR'' stands for [[PTR record]] and sets up the relationship between [[IP address]] and [[hostname]].||Stable
 +
|-
 +
|style="background-color:#fff;"|<code>cnmcyber.com</code>
 +
![[Hostname]]
 +
|The [[hostname]] that points to the [[IP address]].||Selected
 +
|}
 +
 
 +
:[[PTR record]]s are needed for outgoing [[mail server]]s such as [[Postfix]], because most of the mail providers reject or mark as spam messages received by [[mail server]]s without valid reverse dns configuration such as a missing [[PTR record]] or mismatch with an [[A record]] for the [[hostname]].
 +
 
 +
===SRV record===
 +
:''Main wikipage: [[SRV record]]''
  
−
==Security matters==
+
:Any [[SRV record]] is a [[DNS record]] that specifies the location, both [[hostname]] and port number of servers for specific services. ''SRV'' is an abbreviation for ''service''. [[SRV record]]s can be used to direct certain types of traffic to particular servers.
−
As DNS is one of the core technologies used in the delivery of the  
+
 
−
modern Internet, coupled with the high percentage of [[nameserver]]s using
+
===CAA record===
−
the same [[nameserver]] software (BIND), the DNS protocol and servers
+
:''Main wikipage: [[CAA record]]''
−
implementing it are under constant scrutiny from hackers. The following
+
 
−
are two common DNS related attacks:
+
:Any [[CAA record]] is a [[DNS record]] that specifies which certificate authorities are permitted to issue certificates for the host. ''CAA'' is the acronym for ''[[DNS Certification Authority Authorization|Certification Authority Authorization]]'', which is a method for cross-checking security information on the [[Internet]]. [[CAA record]]s can be used to reduce the risk of unintended certificate mis-issue.
−
DNS CACHE POISONING
+
 
−
One of the more common attacks against the DNS protocol is the DNS
+
==Security threats==
−
cache poisoning attack. In order to reduce unnecessary Internet traffic,  
+
Hackers are constantly trying to penetrate ''DNS'' primarily because of two reasons. First, ''DNS'' is used throughout the whole [[Internet]] and, second, the overwhelming majority of host devices utilize the same nameserver software, [[BIND]].
−
most Internet Service Providers (ISP) configure their [[nameserver]]s to  
+
 
−
cache DNS responses for the period defined in the TTL value of the  
+
===Spoofing===
−
requested record set.
+
:''Main wikipage: [[DNS spoofing]]''
−
This allows for all concurrent requests to be served from the local cache  
+
 
−
at the ISP and not require the series of lookups normally required. This
+
:Any [[DNS spoofing]], which is alternatively known as [[DNS spoofing|DNS cache poisoning]], [[DNS spoofing|DNS tampering]], [[DNS spoofing|DNS hijacking]], or [[DNS spoofing|DNS redirection]], is the attack against the [[DNS protocol]] that aims to alternate [[IP address]]es cached by [[DNS resolver]]s for a [[DNS record]] of the attacker choice.
−
results in faster DNS responses for the end user, as well as a decrease in
+
 
−
data costs for the ISP.
+
:In order to increase speed of DNS resolutions for the end user, as well as to decrease costs for [[Internet service provider]]s ([[Internet service provider|ISP]]), they usually configure their [[nameserver]]s to cache DNS responses for the period defined in the TTL value of the requested record set. This allows for all concurrent requests to be served from the local cache at the [[Internet service provider|ISP]] and not require the series of lookups normally required.
−
This mechanism, however, is the target for the DNS cache poisoning
+
 
−
attack. In this attack, the hacker aims to have their IP address cached by
+
:This mechanism, however, is the target for the [[DNS spoofing]] attacks. In these attacks, the attacker aims legitimate [[DNS resolver]]s to have an attacker's IP address cached as a false [[DNS record]]. For instance, this false record can be an [[A record]] or [[NS record]].
−
the ISP"s DNS resolvers for a record of their choosing.
+
 
−
For example, the attacker would seek to have the IP address of the
+
:For example, the attacker would send a fake resolutions to legitimate DNS resolver and seek the attacker's IP address to be cached instead of or in addition to the legitimate IP address. The attacker then could display a fake login page and harvest users' logins and passwords. In the ''Man-In-The-Middle Attack'', the attacker would use the harvested logins and passwords to access the legitimate IP address, so the victim would have regular experience working with familiar resource without knowledge that the attacker is between the victim and the legitimate resource.
−
hostname "login.example.com" be cached with their own IP address
+
 
−
instead of the legitimate IP address. The result of this attack is that anyone
+
:[[DNSSEC]], [[SSL certificate]]s and [[digital signature]]s are most common tools used to prevent [[DNS spoofing]].
−
using that DNS resolver (typically most of that ISP's customers) would be
+
 
−
loading the site "login.example.com" from the hacker's server rather than
+
===Reflection attack===
−
the legitimate server. Once this is achieved, the hacker could potentially
+
:DNS reflection attacks differ from DNS cache poisoning attacks in that their primary goal is not to compromise the integrity of a DNS resolver's data, but rather to completely flood a system with DNS responses, rendering it unable to respond to legitimate queries. This type of attack is known as a Denial of Service (DoS) attack.
−
display a fake login page and harvest users" logins and passwords.
+
 
−
DNS REFLECTION ATTACKS
+
:This attack is conducted by a hacker spoofing the sender IP address of a [[DNS request]] to mimic that of the victim"s server. When the DNS resolver then replies to the query, the response will go to the victim"s server rather than the hackers. This attack works due to the fact that a small DNS query can actually return a response that is many times larger than the query itself.
−
DNS reflection attacks differ from DNS cache poisoning attacks in that  
+
 
−
their primary goal is not to compromise the integrity of a DNS resolver"s  
+
:Hackers leverage this in order to direct a large amount of network (DNS) traffic at the victim"s machine. This results in the victim machine being unable to accept or respond to legitimate traffic.
−
data, but rather to completely flood a system with DNS responses,  
+
 
−
rendering it unable to respond to legitimate queries. This type of attack  
+
==DNSSEC==
−
is known as a Denial of Service (DoS) attack.
+
The original [[DNS protocol]] was never designed with security in mind; user access to the nascent Internet was tightly controlled and not open to public access.
−
DZONE.COM/REFCARDZ
+
 
−
7
+
The [[DNSSEC|Domain Name System Security Extensions]] ([[DNSSEC]]) are an expansion of the [[DNS protocol]] aimed at mitigating a number of security issues that have been identified within the DNS since this time. The [[DNSSEC]] provides the ability for DNS clients to determine that the DNS response they are receiving actually comes from the server [[authoritative nameserver|authoritative]] for the given [[hostname]]. This feature is a direct response to the DNS  
−
PRACTICAL DNS
 
−
BROUGHT TO YOU IN PARTNERSHIP WITH
 
−
This attack is conducted by a hacker spoofing the sender IP address of a  
 
−
DNS query to mimic that of the victim"s server. When the DNS resolver  
 
−
then replies to the query, the response will go to the victim"s server  
 
−
rather than the hackers. This attack works due to the fact that a small  
 
−
DNS query can actually return a response that is many times larger than  
 
−
the query itself.
 
−
Hackers leverage this in order to direct a large amount of network (DNS)  
 
−
traffic at the victim"s machine. This results in the victim machine being  
 
−
unable to accept or respond to legitimate traffic.
 
−
DNSSEC
 
−
The original DNS protocol was never designed with security in mind; user  
 
−
access to the nascent Internet was tightly controlled and not open to  
 
−
public access.
 
−
The Domain Name System Security Extensions (DNSSEC) are an  
 
−
expansion of the DNS protocol aimed at mitigating a number of security  
 
−
issues that have been identified within the DNS since this time. The  
 
−
DNSSEC provide the ability for DNS clients to determine that the DNS  
 
−
response they are receiving actually comes from the server authoritative  
 
−
for the given [[host name|domain name]]. This feature is a direct response to the DNS  
 
 
cache poising attacks described above.
 
cache poising attacks described above.
−
HOW DNSSEC WORKS
+
 
−
DNSSEC is implemented by adding a number of additional records to the  
+
===Security RRs===
−
DNS zone of a domain. These records are as follows:
+
:[[DNSSEC]] is implemented by adding a number of additional records to the DNS zone of a domain. These records are as follows:
−
RECORD NAME
+
:{|class="wikitable" width=100%
−
FUNCTION
+
|style="text-align:center;"|[[DNS record|Record]]
−
RRSIG
+
!Function
−
The signature of the DNS resource record set. This  
+
|-
−
record is returned in the response to any DNS  
+
![[RRSIG record|RRSIG]]
−
query and can be verified by checking against the  
+
|The signature of the DNS resource record set. This record is returned in the response to any DNS query and can be verified by checking against the public key for the domain.
−
public key for the domain.
+
|-
−
DNSKEY
+
![[DNSKEY record|DNSKEY]]
−
Contains the public key for the domain.
+
|Contains the public key for the domain.
−
DS
+
|-
−
The "Delegation Signer" record, used in  
+
![[DS record|DS]]
−
authenticating the DNSKEY for a domain.
+
|The "Delegation Signer" record, used in authenticating the DNSKEY for a domain.
−
NSEC
+
|-
−
Used to prove a name does not exist.
+
![[NSEC record|NSEC]]
−
NSEC3
+
|Used to prove a name does not exist.
−
An alternative version of the traditional NSEC  
+
|-
−
record also provides proof a name doesn"t exist  
+
![[NSEC3 record|NSEC3]]
−
but prevents zonewalking.
+
|An alternative version of the traditional [[NSEC record]] also provides proof a name doesn't exist but prevents zonewalking.
−
NSEC3PARAM
+
|-
−
Parameter record for use with NSEC3.
+
![[NSEC3PARAM record|NSEC3PARAM]]
−
In order for DNSSEC to be functional in any given DNS query, every  
+
|Parameter record for use with NSEC3.
−
authoritative server from the trust anchor (generally the [[TLD  
+
|}
−
nameserver]]s) all the way down to the domain"s nameservers must  
+
 
−
support DNSSEC and offer signing of record sets. If any of these do not  
+
===Setup process===
−
support the extensions, then it is not possible to utilize the benefits of  
+
:In order for [[DNSSEC]] to be functional in any given [[DNS request]], every [[authoritative server]] from the trust anchor (generally the [[TLD nameserver]]s) all the way down to the domain's nameservers must support [[DNSSEC]] and offer signing of record sets. If any of these do not support the extensions, then it is not possible to utilize the benefits of [[DNSSEC]] for that query.
−
DNSSEC for that query.
+
 
−
In order to sign a DNS zone with DNSSEC, a private and public key pair  
+
:In order to sign a [[DNS zone]] with [[DNSSEC]], a private and public key pair is generated by the owner. The public key is listed in the [[DNS zone]] in the [[DNSKEY record]] whilst the private key is stored securely on the [[authoritative nameserver]]. Once this is done, the parent domain server is informed that this zone has been signed.
−
is generated by the owner. The public key is listed in the DNS zone in  
+
 
−
the "DNSKEY" record whilst the private key is stored securely on the  
+
:Each record in the zone is now digitally signed with the signature of the record set stored in the [[RRSIG record]]. This record is the encrypted hash of the original records value. Sent with the response to every [[DNS request]], this [[RRSIG record]]s allows the client to determine if the value received is the same as the one sent by the server.
−
authoritative nameserver. Once this is done, the parent domain server is  
+
 
−
informed that this zone has been signed.
+
:When the client receives the DNS response, it takes the "RRSIG" value, decrypts it with the public key (retrieved from the [[DNSKEY record]]) and then compares the result with the hash of the record value received. If these values match, then the record received is identical to the one sent.
−
Each record in the zone is now digitally signed with the signature of the  
+
 
−
record set stored in the "RRSIG" record. This record is the encrypted  
+
:The next feature of [[DNSSEC]] is the ability to ensure that the server that sent the record and public key is actually the legitimate [[authoritative nameserver]] for that domain. This is achieved using the [[DS record]]. This [[DS record]] stores a digest of the domain's DNS key in the domain's parent zone that is protected by the parent zones "DNSKEY." This configuration then continues in a hierarchical structure up to the [[DNS root zone]]. The data for the [[DNS root zone]] is treated as a "Trust Anchor."
−
hash of the original records value. Sent with the response to every DNS  
+
 
−
query, this "RRSIG" records allows the client to determine if the value  
+
:Using this record, and hierarchical authentication method, it is possible to ensure that the "DNSKEY" received for a domain has not been spoofed by an attacker.
−
received is the same as the one sent by the server.
+
 
−
When the client receives the DNS response, it takes the "RRSIG" value,  
+
===Secured mapping===
−
decrypts it with the public key (retrieved from the "DNSKEY" record) and  
+
:The DNS request process remains quite similar to the standard process of requesting [[DNS record]]s, albeit with a few more pieces of data added in order to verify the responses received.
−
then compares the result with the hash of the record value received. If  
+
 
−
these values match, then the record received is identical to the one sent.
+
:The following is an example workflow and description of a typical DNS request with [[DNSSEC]] enabled. Changes from a normal (non [[DNSSEC]] enabled) DNS request are in italics.
−
The next feature of DNSSEC is the ability to ensure that the server that sent  
+
 
−
the record and public key is actually the legitimate authoritative domain
+
:#The user queries their [[Internet service provider]]'s ([[Internet service provider|ISP]]'s) [[DNS resolver]] asking for the IP address for "www.google.com."
−
server for that domain. This is achieved using the "DS" record. This "DS"
+
:#The DNS resolver asks the [[root nameserver]] where it can find details for "www.google.com," unless it already has the information cached. It also sets the "DNSSEC OK" (DO) bit to signify that it is requesting the [[DNSSEC]] records be returned also.
−
record stores a digest of the domain"s DNS key in the domain"s parent  
+
:#If it is asked, the [[root nameserver]] responds that this information is handled by the .com nameserver. It also sends the [[DS record]] for the .com zone and [[RRSIG record]]s for any records returned with the result. The resolver would then validate that the [[DS record]] value received from the [[root nameserver]] matches the digest of the [[DNSKEY record]] value for the .com zone.
−
zone that is protected by the parent zones "DNSKEY." This configuration  
+
:#The DNS resolver asks the .com nameserver where it can find details for "www.google.com," unless it already has the information cached.
−
then continues in a hierarchical structure up to the DNS root zone. The  
+
:#If it is asked, the .com nameserver responds that this information can be found at the nameservers of google.com. It also sends the [[DS record]] for the google.com zone and [[RRSIG record]]s for any records returned with the result. The resolver would then validate that the [[DS record]] value received from the .com nameserver matches the digest of the [[DNSKEY record]] value for the google.com zone.
−
data for the DNS root zone is treated as a "Trust Anchor."
+
:#The [[DNS resolver]] asks the google.com nameservers where it can find details for "www.google.com," unless it already has the information cached.
−
Using this record, and hierarchical authentication method, it is possible  
+
:#If it is asked, the google.com nameservers have this information and respond with a [[DNS record]] set (RRSET) of all [[A record]]s configured for "www.google.com." It also sends the RRSIG value for the RRSET that was returned. The ISP"s DNS resolver can then validate that the RRSIG value is indeed the signature of the RRSET that is returned by checking it against the [[DNSKEY record]] in the google.com zone. The resolver has now validated that the records themselves have not been tampered with, and also previously validated that the servers that have been involved in receiving the data are trusted by validating the [[DS record]]s against the associated parent's [[DNSKEY record]].
−
to ensure that the "DNSKEY" received for a domain has not been  
+
:#The ISP"s DNS resolver then sends the [[A record]] for "www.google.com" back to the user. The user then knows what [[IP address]] to connect to in order to access "www.google.com."
−
spoofed by an attacker.
+
 
−
DNS REQUEST PROCESS WITH DNSSEC
+
===TLD limitations===
−
The DNS request process remains quite similar to the standard process  
+
Unfortunately, not all top level domains currently support [[DNSSEC]].  
−
of requesting [[DNS record]]s, albeit with a few more pieces of data added in  
 
−
order to verify the responses received.
 
−
The following is an example workflow and description of a typical DNS  
 
−
request with DNSSEC enabled. Changes from a normal (non DNSSEC  
 
−
enabled) DNS request are in italics.
 
−
1.
 
−
The user queries their Internet Service Provider"s (ISP) DNS  
 
−
resolver asking for the IP address for "www.google.com."
 
−
2.
 
−
The DNS resolver asks the [[root nameserver]] where it can  
 
−
find details for "www.google.com," unless it already has the  
 
−
information cached. It also sets the "DNSSEC OK" (DO) bit to  
 
−
signify that it is requesting the DNSSEC records be returned also.
 
−
3.
 
−
If it is asked, the [[root nameserver]] responds that this information  
 
−
is handled by the .com nameserver. It also sends the DS record for  
 
−
the .com zone and RRSIG records for any records returned with  
 
−
the result. The resolver would then validate that the DS record  
 
−
value received from the [[root nameserver]] matches the digest of  
 
−
the DNSKEY record value for the .com zone.
 
−
DZONE.COM/REFCARDZ
 
−
8
 
−
PRACTICAL DNS
 
−
BROUGHT TO YOU IN PARTNERSHIP WITH
 
−
4.
 
−
The DNS resolver asks the .com nameserver where it can  
 
−
find details for "www.google.com," unless it already has the  
 
−
information cached.
 
−
5.
 
−
If it is asked, the .com nameserver responds that this information  
 
−
can be found at the nameservers of google.com. It also sends the DS  
 
−
record for the google.com zone and RRSIG records for any records  
 
−
returned with the result. The resolver would then validate that the  
 
−
DS record value received from the .com nameserver matches the  
 
−
digest of the DNSKEY record value for the google.com zone.
 
−
6.
 
−
The DNS resolver asks the google.com nameservers where it  
 
−
can find details for "www.google.com," unless it already has the  
 
−
information cached.
 
−
7.
 
−
If it is asked, the google.com nameservers have this information  
 
−
and respond with a DNS record set (RRSET) of all "A" records
 
−
configured for "www.google.com." It also sends the RRSIG value  
 
−
for the RRSET that was returned. The ISP"s DNS resolver can then  
 
−
validate that the RRSIG value is indeed the signature of the RRSET  
 
−
that is returned by checking it against the DNSKEY record in the  
 
−
google.com zone. The resolver has now validated that the records  
 
−
themselves have not been tampered with, and also previously  
 
−
validated that the servers that have been involved in receiving  
 
−
the data are trusted by validating the DS records against the  
 
−
associated parent"s DNSKEY record.
 
−
8.
 
−
The ISP"s DNS resolver then sends the "A" record for "www.
 
−
google.com" back to the user. The user then knows what IP  
 
−
address to connect to in order to access "www.google.com."
 
−
DNSSEC AVAILABILITY
 
−
Unfortunately, not all top level domains currently support DNSSEC.  
 
 
As was previously mentioned, each server in the chain needs to both  
 
As was previously mentioned, each server in the chain needs to both  
−
support DNSSEC as well as have the appropriate records configured in  
+
support [[DNSSEC]] as well as have the appropriate records configured in  
−
order for DNSSEC to have any effect.
+
order for [[DNSSEC]] to have any effect.
 
As of April 2013, less than a third of all top level domain servers  
 
As of April 2013, less than a third of all top level domain servers  
 
(including ccTLD's) are configured with the appropriate settings to  
 
(including ccTLD's) are configured with the appropriate settings to  
−
support DNSSEC.
+
support [[DNSSEC]].
 
Of the 19 globally assigned top level domains, the following do not  
 
Of the 19 globally assigned top level domains, the following do not  
−
currently support DNSSEC:  
+
currently support [[DNSSEC]]:  
 
•  
 
•  
 
.aero,
 
.aero,
Line 587: Line 580:
 
•  
 
•  
 
.xxx
 
.xxx
−
COMMON DNS PROBLEMS
 
−
DNS PROPAGATION
 
−
The most common problem encountered with the DNS protocol is the
 
−
situation known as "DNS Propagation." When a change is made to a DNS
 
−
zone, this change is not immediately seen by the rest of the world.
 
−
The name itself (specifically the "propagation" component) suggests
 
−
that changes propagate outwards across the Internet away from the
 
−
server on which the change was made. This is a common misconception:
 
−
DNS changes do not propagate outwards like ripples. Instead, when a
 
−
change is made on a DNS zone, the only real automated propagation of
 
−
that change is to secondary or child nameservers. Due to the nature of
 
−
DNS, all DNS queries for a particular domain will follow the hierarchical
 
−
approach to determining which server has the data for that domain,
 
−
eventually arriving at the nameserver for the domain.
 
−
As the change to the DNS zone has already occurred on the primary
 
−
server, the updated values are immediately available and are included in
 
−
all DNS responses made by that server after the change has been made.
 
−
Once the change has been made on the primary server, each additional
 
−
authoritative nameserver will update its stored values the next time it
 
−
attempts a zone transfer.
 
−
The "propagation" effect is actually caused by ISP"s DNS resolvers
 
−
caching the original, now outdated, DNS records and returning that
 
−
to the end user, rather than the updated value that could be retrieved
 
−
directly from the domain"s nameservers.
 
−
The TTL value assigned to each record indicates to DNS resolvers how
 
−
long they should cache the values of the retrieved DNS records.
 
−
Ideally, if a change were made to a DNS record immediately after it was
 
−
cached by a DNS resolver, the delay before that resolver retrieved the
 
−
updated record would be at most the value of that record sets TTL.
 
−
While not as common in recent times, not all DNS resolvers adhere
 
−
to the values contained in the TTL values, with many choosing to
 
−
implement their own TTL values for cached records (in order to reduce
 
−
bandwidth use). This is where the "propagation" effect comes from.
 
−
In order to reduce the likelihood of a long DNS propagation time, try this:
 
−
1.
 
−
Ensure that the TTL values of all records are set to a low value
 
−
(e.g. 300).
 
−
2.
 
−
Ensure that when changing nameservers both the old and the
 
−
new nameservers are configured with the same DNS records.
 
−
This will ensure that regardless of what nameserver the user is
 
−
directed to, the results they receive will be consistent.
 
−
DZONE.COM/REFCARDZ
 
−
9
 
−
PRACTICAL DNS
 
−
BROUGHT TO YOU IN PARTNERSHIP WITH
 
−
WEBSITE NOT AVAILABLE ON "WWW." HOSTNAME
 
−
Another common issue with DNS configuration is users' experiencing
 
−
difficulties accessing their website using "www.example.com" rather
 
−
than just "example.com."
 
−
The cause of this issue is actually quite simple to diagnose as well as
 
−
resolve. The ideal configuration of the DNS zone to allow the "www."
 
−
hostname to work is as follows:
 
−
1.
 
−
Ensure that there is an "A" record for the domain itself. example.
 
−
com. IN A 192.168.0.1
 
−
2.
 
−
Next, create a CNAME record for the "www." [[host name]]. www.
 
−
example.com. IN CNAME example.com
 
−
The above steps will (as far as DNS is concerned) ensure that the website
 
−
is visible on both "www.example.com" as well as "example.com." It is
 
−
then the responsibility of the web server to determine whether to force
 
−
redirect the user to one or the other.
 
−
There are other methods to solve this issue, including adding an A record
 
−
for both the domain itself as well as the "www." [[host name]] (instead of a
 
−
CNAME record); however for ease of maintenance, the use of a CNAME
 
−
record is recommended as if the IP address needs to be changed in
 
−
future, it only needs to be changed once.
 
−
NAMESERVER REDUNDANCY
 
−
For most [[host name|domain name]] owners, configuring a domain's nameservers is as
 
−
simple as entering the values given to them by their web hosting company.
 
−
For example: ns1.webhost.com and ns2.webhost.com
 
−
It is important to check, however, that your provider"s nameservers are:
 
−
a.
 
−
Not located on the same server as the website itself; and
 
−
b.
 
−
Located in geographically diverse locations.
 
−
A large number of providers use the web hosting control panel "cPanel"
 
−
which by default allows the provider to configure the nameservers, web
 
−
server and mail server to be located on the same physical server. This
 
−
means that should the server itself go offline for whatever reason, your
 
−
website and email are completely offline.
 
−
Ideally, you should ensure that your web host has at least its [[nameserver]]s
 
−
located on separate physical servers as well as networks to your web
 
−
server and mail server. This provides a layer of defense in that if the DNS
 
−
service fails to work on one of your nameservers due to a network or
 
−
hardware issue, the other nameserver is still able to respond, and the
 
−
website and mail server will remain unaffected.
 
−
DZone, Inc.
 
−
150 Preston Executive Dr. Cary, NC 27513
 
−
888.678.0399    919.678.0300
 
−
Copyright © 2018 DZone, Inc. All rights reserved. No part of this publication
 
−
may be reproduced, stored in a retrieval system, or transmitted, in any form
 
−
or by means electronic, mechanical, photocopying, or otherwise, without
 
−
prior written permission of the publisher.
 
−
DZone communities deliver over 6 million pages each month
 
−
to more than 3.3 million software developers, architects
 
−
and decision makers. DZone offers something for everyone,
 
−
including news, tutorials, cheat sheets, research guides, feature
 
−
articles, source code and more. "DZone is a developer’s dream,"
 
−
says PC Magazine.
 
−
Written by
 
−
Michael Hughes,
 
−
Lead Security Specialist, National Australia Bank
 
−
Michael Hughes has worked for energy companies, web hosting companies and large financial institutions as a technical
 
−
specialist and, more recently, a security specialist. Michael has a Bachelors Degree in Telecommunications Engineering,
 
−
and has developed a deep knowledge of many technologies over his career. While working for one of the larger web
 
−
hosting companies in Australia, Michael developed ViewDNS.info with the aim of providing a free and simple interface to a
 
−
large number of DNS tools.
 
  
−
==Software==
+
==Issues==
−
===Nameserver software===
+
 
−
As there are a large number of different [[nameserver]] software packages,  
+
===Propagation===
−
the format of these zone files can vary slightly between different
+
:The most common problem encountered with the DNS protocol is the situation known as "DNS Propagation." When a change is made to a [[DNS zone]], this change is not immediately seen by the rest of the world.
−
implementations. The most widely-used DNS software on the Internet
+
 
−
today is the Berkeley Internet Name Domain (BIND) [[nameserver]].
+
:The name itself (specifically the "propagation" component) suggests that changes propagate outwards across the Internet away from the server on which the change was made. This is a common misconception: DNS changes do not propagate outwards like ripples. Instead, when a change is made on a DNS zone, the only real automated propagation of that change is to [[secondary nameserver]]s. Due to the nature of DNS, all DNS queries for a particular domain will follow the hierarchical approach to determining which server has the data for that domain, eventually arriving at the nameserver for the domain.
−
Originally written in 1984 by four Berkeley College students as a
+
 
−
graduate project, the BIND [[nameserver]] was eventually rewritten in
+
:As the change to the DNS zone has already occurred on the [[primary nameserver]], the updated values are immediately available and are included in all DNS responses made by that server after the change has been made.
−
2000 with contributions coming from a number of large organizations
+
 
−
including IBM, Hewlett Packard, Compaq, and Sun Microsystems.
+
:Once the change has been made on the [[primary nameserver]], each additional [[authoritative nameserver]] will update its stored values the next time it attempts a zone transfer.
−
This rewrite was labeled version 9 and is currently still the supported
+
 
−
version of the BIND [[nameserver]] in use on systems around the world (and
+
:The "propagation" effect is actually caused by ISP's [[DNS resolver]]s caching the original, now outdated, [[DNS record]]s and returning that to the end user, rather than the updated value that could be retrieved directly from the domain"s nameservers.
−
also used by the majority of DNS [[root nameserver]]s themselves). Below is an
+
 
−
example of a zone file for the BIND 9 [[nameserver]]:  
+
:The [[TTL]] value assigned to each record indicates to [[DNS resolver]]s how long they should cache the values of the retrieved [[DNS record]]s.
−
~
+
 
−
$TTL 14400
+
:Ideally, if a change were made to a [[DNS record]] immediately after it was cached by a [[DNS resolver]], the delay before that resolver retrieved the updated record would be at most the value of that record sets TTL.
−
$ORIGIN example.com.  
+
 
−
@ 14400 IN SOA ns1.example.com.  admin.example.com. (   
+
:While not as common in recent times, not all [[DNS resolver]]s adhere to the values contained in the TTL values, with many choosing to implement their own TTL values for cached records (in order to reduce bandwidth use). This is where the "propagation" effect comes from.
−
                                2012121902 ;
+
 
−
                                3600; refresh seconds
+
:In order to reduce the likelihood of a long DNS propagation time, try this:
−
                                600; retry
+
:#Ensure that the TTL values of all records are set to a low value (e.g. 300).
−
                                86400; expire
+
:#Ensure that when changing nameservers both the old and the new nameservers are configured with the same DNS records. This will ensure that regardless of what nameserver the user is directed to, the results they receive will be consistent.
−
                                3600; minimum
+
 
−
                                );
+
===Not found WWW-hostname===
−
IN A 12.34.56.78
+
:Another common issue with DNS configuration is users' experiencing difficulties accessing their website using "www.example.com" rather than just "example.com."
−
IN NS ns1.example.com.  
+
 
−
IN NS ns2.example.com.  
+
:The cause of this issue is actually quite simple to diagnose as well as resolve. The ideal configuration of the [[DNS zone]] to allow the "www." hostname to work is as follows:
−
ns1 IN A 11.11.11.11
+
:#Ensure that there is an [[A record]] for the domain itself. example.com. IN A 192.168.0.1
−
ns2 IN A 22.22.22.22
+
:#Next, create a [[CNAME record]] for the "www." [[hostname]]. www.example.com. IN CNAME example.com.
−
www IN CNAME example.com.  
+
 
−
ftp IN CNAME example.com.  
+
:The above steps will (as far as DNS is concerned) ensure that the website is visible on both "www.example.com" as well as "example.com." It is then the responsibility of the web server to determine whether to force redirect the user to one or the other. There are other methods to solve this issue, including adding an [[A record]] for both the domain itself as well as the "www." [[hostname]] (instead of a [[CNAME record]]); however for ease of maintenance, the use of a [[CNAME record]] is recommended as if the IP address needs to be changed in future, it only needs to be changed once.
−
mail IN MX 10 example.com.
+
 
−
DNS zone file example (BIND [[nameserver]])
+
===NS redundancy===
 +
:For most [[hostname]] owners, configuring a domain's nameservers is as simple as entering the values given to them by their web hosting company. For example: ns1.webhost.com and ns2.webhost.com
 +
 
 +
:It is important to check, however, that your provider"s nameservers are:
 +
:#Not located on the same server as the website itself; and
 +
:#Located in geographically diverse locations.
 +
 
 +
:A large number of providers use the web hosting control panel "cPanel" which by default allows the provider to configure the nameservers, web server and [[mail server]] to be located on the same physical server. This means that should the server itself go offline for whatever reason, your website and email are completely offline.
 +
 
 +
:Ideally, you should ensure that your web host has at least its [[nameserver]]s located on separate physical servers as well as networks to your web server and [[mail server]]. This provides a layer of defense in that if the DNS service fails to work on one of your nameservers due to a network or hardware issue, the other nameserver is still able to respond, and the website and [[mail server]] will remain unaffected.
 +
 
 +
==Tools==
 +
===Validation===
 +
:https://intodns.com/
 +
 
 +
==See also==
 +
 
 +
===Related lectures===
 +
:*[[DNS of CNM Cloud]].
  
−
===Webserver software===
+
[[Category: CNM Cyber Orientation]][[Category: Articles]]

Latest revision as of 02:51, 5 August 2023

DNS is the acronym for Domain Name System, which is a hierarchical and decentralized domain name system that was originally created to link human-recognizable domain names to machine-processed Internet protocol addresses (IP addresses), and later came to be used to determine other data of these names and addresses.

Originally created for name mapping, DNS today also defines technical settings for its core mapping service. In addition, DNS is used to set up functionality for the emails using DNS record such as MX and TXT records. For example, a public key to sign mail can be added to text records.

DNS records are contained in so-called DNS zones, which Internet service providers (ISPs) store.


Functionality

Name mapping

First of all, DNS is a hierarchical and decentralized system that maps human-readable names, called hostnames, and digital addresses such as IP addresses of the resources connected to a network such as the Internet.
On the Internet, DNS stores both hostnames and IP addresses together for the purpose of mapping any hostname to one or more IP addresses or, vice versa, mapping an IP addresses to its hostname.
For instance, a user may request its web browser to display some website, while providing this browser with some hostname (also known as domain name). DNS is responsible for locating the sought website in the World Wide Web and granting the user's web browser with the right IP address.
To decentralize, DNS designates authoritative nameservers for each host or host device connected to the network. This structure provides distributed and fault-tolerant service and was designed to avoid a single large central database.

Naming arrangements

In addition to name mapping, DNS defines the DNS protocol, which is the model of the data structures and communication exchanges including TTLs that are used to propagate DNS records through the system.

Email and text functions

Finally, DNS is used to set up properties for:
  • SMTP mail exchangers using MX and other DNS records. DNS may be particularly useful in combating unsolicited email messages known as spam by storing a real-time blackhole list (RBL);
  • Human-readable texts about the resource and/or machine-readable data using TXT records. This data can be used for verification of domain ownership, email owner verification, and much more.

Hostnames

Main wikipage: Hostname

On the Internet, a hostname is a human-readable alias that is assigned to a particular IP address. This alias is used to identify the IP address of the needed device in various forms of electronic communication, such as the World Wide Web and emails. Earlier, a hostname was often called a domain name; these two terms can be used interchangeably. The hostname is the central part of any URL.

Purpose

Computer networks usually assign those computing devices that are connected to that network some numerical addresses. However, these addresses are rarely convenient for human being to use.
DNS has been created in order to help human beings to identify a particular computer, called a host device or, simply, host, in a network, most notably, on the Internet, using some names that those human beings can recognize. DNS supplements a numerical address such as 176.056.230.964 of the host device with some human-readable, human-recognizable hostname (also known as domain name) such as wiki.cnmcyber.com that may contain not necessarily just digits and computer symbols, but also letters, words, or some combinations of those.

Right-to-left label hierarchy

Every hostname consists of two or more labels separated by dots. Those labels are ranged hierarchically from right to left. Each label on the left is classified as a subdomain of the label to its right. For instance, in the hostname, wiki.cnmcyber.com:
Domain name wiki . cnmcyber . com
Description The label for the third level domain, which could also be defined as the second level subdomain. Separator (a dot) The label for the second level domain or, in other words, the TLD subdomain. Separator (a dot) The label for the top level domain (TLD)
Directing‑to server Host TLD Root
Managing server Host Host TLD

Name requirements

Technically, there is no limit on the number of the levels; however, there are some other restrictions. According to the DoD Host Table Specification, in order to be able to serve as a hostname, some combination of labels shall be associated with one or more IP addresses and comply with the following rules:
  • A hostname must be a text string consisting of only the letters A through Z (upper or lower case), digits 0 through 9, the minus sign (-), and the period (.);
  • No hostname can contain any spaces;
  • The first character must be an alphabetic character or a digit;
  • The last character cannot be a minus sign or a period;
  • The recommended length for a hostname is up to 24 characters.
If the hostname is completely specified, including a top-level domain of the Internet, then the hostname is said to be a fully qualified domain name (FQDN).

Registrars and resellers

Hostnames are registered by special entities called registrars. These registrars usually create initial DNS records as well. Those registrars may also hire other entities called hostname resellers to sell the registration services. Some registrars and all known resellers are also Internet service providers (ISPs).

Internet service providers

Main wikipage: Internet service provider
Any Internet service provider, which is also known by its acronym, ISP, is a legal entity that provides Internet services such as Internet access, Internet transit, hostname registration, web hosting, Usenet service, and colocation.

Delivery scheme

A delivery scheme is an officially organized plan for delivery.

Unicast

Unicast is a delivery scheme that routes transfer from one source address to a single specified destination address. Unicast is the dominant form of delivery on the Internet.

Broadcast

Broadcast is a delivery scheme that routes transfer from one source address to all destination addresses in the network.

Multicast

Multicast is a delivery scheme that routes transfer from one source address to a group of destination addresses, usually the ones that have expressed interest in receiving the deliverable.

Anycast

Main wikipage: Anycast
Anycast is a delivery scheme that routes transfer from one source address to any one out of a group of destination addresses, selected based on some algorithm and/or criteria. The selected route is often the one that is the nearest and/or fastest accessible to the source.
On the Internet, anycast is the network addressing and routing technique that assures that one IP address has multiple routing paths and the best ones are chosen for every single delivery. This type of redundancy serves two main purposes:
  1. To ensure speedy responses to DNS queries (by providing network-topologically best routes to the root nameservers); and
  2. To minimize the likelihood of an outage of the entire DNS system.
DNS resolvers select the desired path on the basis of number of hops, distance, lowest cost, latency measurements, or based on the least congested route. Anycast networks are widely used for content delivery network (CDN) products to bring their content closer to the end user.

Geocast

Geocast is a delivery scheme that routes transfer from one source address to a group of destination addresses based on geographic location.

System structure

Domain levels

The DNS hierarchy is built of three levels:
  1. The root domains are responsible for locating TLD nameservers;
  2. The top level domains (TLDs) are responsible for locating host nameservers;
  3. The host domains are responsible for any DNS records beyond TLD.

Infrastructure

Main wikipage: DNS infrastructure
DNS infrastructure is designed in a distributed manner. The infrastructure consists of four actors -- DNS resolvers, root nameservers, TLD nameservers, and host nameservers -- that accommodate the process from entering a human readable hostname into a web browser to pointing this web browser to the exact IP address.

Resolvers

Main wikipage: DNS resolver
DNS resolvers moderate any process of translating (resolving) human readable hostnames into IP addresses that are used in communication between Internet hosts. DNS resolvers receive requests in the form of a hostname from a web browser and request the needed data from root nameservers, which are the highest in the hierarchy, if DNS resolvers haven't already cached that data. Indeed, DNS resolvers not only redirect requests, but also cache the data needed to identify IP addresses.

Protocol

Any DNS protocol is the model of the data structures and communication exchanges including TTLs that are used to propagate DNS records through the system. The traditional DNS protocol doesn't address security challenges. The security-sensitive protocol is DNSSEC.

Non-secured mapping

The complete name-to-IP-address process can be described in the following way:
  1. When the user enters a hostname into a web browser, this browser queries their Internet service provider's (ISP's) DNS resolver asking for the IP address.
  2. The DNS resolver asks the root nameserver where it can find details for that hostname, unless the resolver already has its IP address data cached.
  3. If it is asked, the root nameserver responds what TLD nameserver handles this data.
  4. The DNS resolver asks the TDL nameserver where it can find details for the entered hostname, unless it already has the data cached.
  5. If it is asked, the TLD nameserver responds that this data can be found at the host nameservers.
  6. The DNS resolver asks the host nameservers where it can find details for the needed IP address, unless it already has the data cached.
  7. If it is asked, the host nameservers have this data and respond with a DNS record containing the IP address for the entered hostname.
  8. The ISP's DNS resolver sends the identified data back to the web browser. The name-to-IP-address process has been accomplished. Based on its results, the web browser points its request to the exact IP address in order to establish communication between this browser and that domain.

Data structures

Communication exchanges

Servers

Main wikipage: Nameserver

Nameservers are servers that respond to DNS requests using appropriate protocol. DNS-сервер, host nameserver — приложение, предназначенное для ответов на DNS-запросы по соответствующему протоколу. Также DNS-сервером могут называть хост, на котором запущено соответствующее приложение.

Roles

Different nameservers are responsible for different operations and play different roles:

Functions

With regard to their functions, nameservers can be divided in several types; however, one nameserver can perform several functions:

Zones

Main wikipage: DNS zone
All DNS data is stored in three types of areas called zones:
Zone What data is stored Nameserver
Root DNS All the data needed to locate TLD nameservers Root NS
TLD DNS All the data needed to locate host nameservers TLD NS
Host DNS All the data related to a particular host, usually in a structured text file that is called the zone file, but other database systems are common as well. Because users can commonly access and host administrators can administer only that data, DNS zone commonly refers to this type of areas Host NS

BIND (NS software)

As there are a large number of different nameserver software packages, the format of these zone files can vary slightly between different implementations. The most widely-used DNS software on the Internet today is the Berkeley Internet Name Domain (BIND) nameserver.
Originally written in 1984 by four Berkeley College students as a graduate project, the BIND nameserver was eventually rewritten in 2000 with contributions coming from a number of large organizations including IBM, Hewlett Packard, Compaq, and Sun Microsystems.
This rewrite was labeled version 9 and is currently still the supported version of the BIND nameserver in use on systems around the world (and also used by the majority of DNS root nameservers themselves). Below is an example of a zone file for the BIND 9 nameserver:

~
$TTL 14400
$ORIGIN example.com.
@ 14400 IN SOA ns1.example.com. admin.example.com. (
   2012121902 ;
   3600; refresh seconds
   600; retry
   86400; expire
   3600; minimum
      );
IN A 12.34.56.78
IN NS ns1.example.com.
IN NS ns2.example.com.
ns1 IN A 11.11.11.11
ns2 IN A 22.22.22.22
www IN CNAME example.com.
ftp IN CNAME example.com.
mail IN MX 10 example.com.
DNS zone file example (BIND nameserver)

Domain level servers

Root servers

Main wikipage: Root nameserver
Root nameservers are responsible for the initial delegation of requests received from DNS resolvers to the correct TLD nameservers. The DNS root zone defines 13 hostnames for root nameservers, every of which starts with a letter from a to m and ends in .root-servers.net. The letters are assigned to different organizations called operators; however, Verisign currently manages both a and j:
Letter IPV4 address IPV6 address Operator
a 198.41.0.4 2001:503:ba3e::2:30 Verisign
b 192.228.79.201 N/A USC-ISI
c 192.33.4.12 N/A Cogent Communications
d 199.7.91.13 2001:500:2d::d University of Maryland
e 192.203.230.10 N/A NASA
f 192.5.5.241 2001:500:2f::f Internet Systems Consortium
g 192.112.36.4 N/A Defense Information Systems Agency
h 128.63.2.53 2001:500:1::803f:235 U.S. Army Research Lab
i 192.36.148.17 2001:7fe::53 Netnod
j 192.58.128.30 2001:503:c27::2:30 Verisign
k 193.0.14.129 2001:7fd::1 RIPE NCC
l 199.7.83.42 2001:500:3::42 ICANN
m 202.12.27.33 2001:dc3::35 WIDE Project
13 hostnames of root nameservers, but a majority of the IP addresses assigned to the root nameserver are anycast addresses. For instance, l.root-servers.net, which ICANN manages, is a cluster of over 130 physical servers that have the same IP address, but distributed around the globe.
The United States Department of Commerce controls the DNS root zone. This department delegated its management to the Internet Assigned Numbers Authority (IANA). The IANA has hired the Internet Corporation for Assigned Names and Numbers (ICANN) to manage DNS root zone, but the United States Department of Commerce still needs to approve any changes proposed for the DNS root zone.

TLD servers

Main wikipage: TLD nameserver
TLD nameservers handle DNS records related to top level domains (TLD) such as .com, .org, and .net.

Host servers

Main wikipage: Host nameserver
The configured host nameservers handle DNS records such as hostname (also known as domain name), IP address, hostname aliases, mail server details, for a particular host device. The configured means that someone needs to configure its DNS zone, which are usually bundled into one zone file. The zone file contains DNS records of all domains for which the given nameserver is authoritative.
Hostname registrars usually provide hostname buyers with default files that often list an A record and NS records, but owners of hostnames can alternate almost any DNS record for their host. The SOA record is the exception; rarely, hostname registrars allow hostname buyers alternating that.

Requests

Main wikipage: DNS request

A DNS request is a query to obtain DNS records for a particular host device in some network.

Directions

  1. A forward request is a DNS request made in order to obtain the IP address based on its hostname.
  2. A reverse request is a DNS request made in order to obtain the hostname based on its IP address.

Ports

According to RFC 1035 standard, all nameservers respond using port 53 TCP and UDP. Early versions of BIND used the same port for requesting, but contemporary servers use any available non-registered ports.

Query methods

Any DNS request, either forward or reverse, can be resolved using one or more methods.

Recursive query

Any recursive query is the DNS query that the nameserver resolves completely, while asking other nameservers when the requested server needs more data. In other words, any recursive query expects the final answer from the requested server. That server is supposed to accomplish any research if that research is needed.
However, nameservers are not required to fully resolve recursive queries.

Non-recursive query

Any non-recursive query is the DNS query that the nameserver resolves, without asking other nameservers when the requested server needs more data. In other words, any recursive query expects the partial, but quick answer from the requested server. That server is not supposed to accomplish any research. This nameserver may resolve that query:
  • Completely if this nameserver is authoritative and responsible for the requested zone;
  • Probably if this nameserver and/or the requesting DNS resolver has some cached data;
  • Negatively if neither this nameserver nor the requesting DNS resolver has any cached data.

Iterative query

Any iterative query is the DNS query that the DNS resolver continues while querying one or more nameservers in chain until the request has been resolved completely by the authoritative server that is responsible for the particular zone.

Method combinations

The resolution process may combine various methods, which may be used simultaneously.
Some nameservers allows for working using different methods or combinations of methods in different segments. This feature is called "view" in BIND. For instance, local IP addresses such as 10.0.0.0/8 can receive local addresses of host devices, while DNS requests from the outside of the network would be resolved using external addresses;
A nameserver may also be authoritative for a particular zone for a particular range of IP addresses. For example, the server located at 10.0.0.0/8 announces itself authoritative for the internal zone; so, any request from the external servers to get data on the internal zone would be resolved as "unknown."

Records

Main wikipage: DNS record

Any DNS record (officially known as resource record or RR) is a critical property assigned to a hostname. Each DNS record is stored in a zone file. While being initially created as a name-to-IP address mapping database, DNS also allows for more details that DNS records provide. They may include email addresses, aliases, anti-spam data, and other data.

SOA record

Main wikipage: SOA record
The SOA record is a mandatory DNS record for any DNS zone that states that this particular nameserver is the authoritative server for the requested hostname. SOA stands for Start Of Authority. An example record is as follows:

cnmcyber.com. 14400 IN SOA ns1.cnmcyber.com. admin.opplet.net. (
   2019021701; serial number
   86460; refresh seconds
   600; retry seconds
   86400; expire seconds
   3600; minimum TTL seconds   );

There are many forms of the SOA record. The same example can be written in a shorter form: @ 14400 IN SOA ns1.cnmcyber.com admin.opplet.net 2019021701 86460 600 86400 3600, where:
Sample code Field Description Values
@ Current origin A free standing "@" encodes the name of the host in which this record is located. Hostname
14400 TTL The number of seconds for which the record may be cached by client side programs. If it is set as 0, it indicates that the record should not be cached. From 0 to 2147483647
IN Class The Internet or intranet; other options are all outdated. IN
SOA Record SOA stands for SOA record and sets up the start of authority Stable
ns1.cnmcyber.com Nameserver The nameserver in which the zone file is located; this is the primary nameserver for the host device. Assigned
admin.opplet.net Email address The administrative email contact for the DNS zone. This record indicates the responsible party for the host. The actual email contact in this example is admin@opplet.net. The "." replaces the "@" symbol in DNS zone because the "@" symbol encodes the current origin. Vary
2019021701 Serial number The "serial number" value is created in the YYYYMMDDNN (YYYY for a year, MM for a month, DD for a date, and NN for a sequential number) format for version control. This control is vital because of the need to configure multiple nameservers. The value in the example is made up from the year of 2019, February (month #02), 17th (for a day), and revision number 01. This serial number is a timestamp that changes whenever the host is updated. Automatic
86460 Refresh The number of seconds before the zone should be refreshed. This value sets up how long a secondary nameserver shound wait before checking whether updates have been made on the primary nameserver. When checking, the secondary nameserver will check the serial number of the zone on the master server, and if different will request a zone transfer to update its local copy. The same value of the sample can be written as 24h1m since 86,460 seconds are equal to 24 hours and one minute. Usually, from 6 to 24 hours
600 Retry The number of seconds before a failed refresh should be retried. This value sets up how long a secondary nameserver will wait to retry a zone transfer in the event the initial attempt fails. This value is not significant. Usually, a fraction of the Refresh
86400 Expire The upper limit in seconds before a zone is considered no longer authoritative. This value sets up how long a secondary nameserver will continue to attempt a zone transfer before giving up. If this value is reached before a successful zone transfer is made, the secondary nameserver will expire its local zone file and stop responding to user queries. Usually, from 14 to 28 days
3600 Minimum TTL The negative result TTL (for example, how long a DNS resolver should consider a negative result for a subdomain to be valid before retrying). This value sets up how long a DNS cache may hold a negative value (e.g. an error message) before requesting fresh copies. In the SOA record, this field is the most important. If your DNS information keeps changing, keep it down to a day or less. Otherwise if your DNS record doesn’t change regularly, step it up between 1 to 5 days. The benefit of keeping this value high, is that your website speeds increase drastically as a result of reduced lookups. Caching servers around the globe would cache your records and this improves site performance. Depends on the need

A record

Main wikipage: A record
Any A record is the DNS record that translates a hostname into an IPv4 address. In other words, A records set up relationships between:
  1. Hostnames, which are human-friendly names, and
  2. IPv4 addresses, which are IP addresses expressed using the IPv4 standard.
A PTR record can set up the opposite relationship. The sample of the A record is as follows: cnmcyber.com IN A 159.89.93.1, where:
Sample code Field Description Values
cnmcyber.com Labels One or more labels of the hostname and TLD name. Selected
IN Class The Internet or intranet; other options are all outdated. IN
A Record A stands for A record and sets up the relationship between hostname labels and IP address Stable
159.89.93.1 IPv4 address The location that the resulting hostname points to. Assigned

AAAA record

Main wikipage: AAAA record
Any AAAA record is the DNS record that sets up a relationship between:
  1. A hostname, which is a human-friendly name, and
  2. An IPv6 address, which is an IP address expressed using the IPv6 standard.
AAAA records are similar to A records. The only difference is that A records point to IPv4 addresses and AAAA records do to IPv6 addresses.

NS record

Main wikipage: NS record
Any NS record is the DNS record that specifies authoritative nameservers for the hostname. NS is the acronym for name server.
Each NS record consists of both the hostname and nameserver hostname. It can be formatted as follows:

cnmcyber.com. IN NS ns1.digitalocean.com

Two different authorities, hostname registrars or resellers and host owner, can set these records up. Two different values should be configured to match; otherwise, some problems may occur.

CNAME record

Main wikipage: CNAME record
Any CNAME record is the DNS record that sets up an alias for another hostname. CNAME is an abbreviation for canonical name. Particularly, CNAME records are useful when several hostnames are located on the same IP address. For instance, www.cnmcyber.com. IN CNAME cnmcyber.com. would point any visitor of www.cnmcyber.com to cnmcyber.com (without www.).
Each CNAME record shall point to another valid hostname, either within the same domain or even a completely different domain. Preferably, this record shall point to the hostname that is configured in an A record.

MX record

Main wikipage: MX record
Any MX record is the DNS record that identifies the server that handles email address for the hostname. MX is an abbreviation for mail exchanger.
Each MX record contains three pieces of information: the hostname, the priority, and the hostname of the mail server that handles mail for the host device. The sample of the MX record is as follows: cnmcyber.com IN MX 10 cnmcyber.com, where:
Sample code Field Description Values
cnmcyber.com Labels One or more labels of the hostname and TLD name. Selected
IN Class The Internet or intranet; other options are all outdated. IN
MX Record MX stands for MX record and sets up the relationship between hostname labels and IP address Stable
10 Priority A numerical value that signifies the priority of this particular MX record and, consequently, for the mail server. The values used for this are only important if more than one mail server is used. The lower the value of the priority field, the higher the priority of the mail server. Assigned
mail.cnmcyber.com Mail server hostname The hostname of the mail server that handles email for this domain. This hostname is a google address when Google Apps handle emails for this host device. Any mail server hostname should have a validly configured A record in order to receive emails smoothly. Assigned

TXT record

Main wikipage: TXT record
Any TXT record is a DNS record that allows for storage of human-readable and machine-readable texts that, if posted, would be assigned to a specific hostname.
With regard to machine-readable texts, TXT records may serve multiple purposes, including:
  • Sender policy framework (SPF) data storage. This data confirms the actual systems that are authorized to send mail on behalf of the given hostname. This is useful in the prevention of spam emails being sent with a forged sender address originating from the particular host device. RFC 4408 discourages this practice as "not optimal," however, because SPF now has its own DNS resource record type (code 99);
  • DomainKeys Identified Mail (DKIM) data. This data allows a receiving mail server to authenticate entities that have signed a specific email message. DKIM is similar to SPF in that it can help reduce spam email from containing forged email addresses originating from your domain, but it also contains a large amount of additional functionality.

PTR record

Main wikipage: PTR record
Any PTR record is a DNS record that translates a hostname into an IP address. PTR is an abbreviation for pointer; PTR records point to IP addresses. In comparison with A records, PTR records perform the exact opposite function.
PTR records use the following format: <IP address in a reverse order>.in-addr.arpa PTR <hostname>. For instance, 1.93.89.159.in-addr.apra PTR cnmcyber.com, where:
Sample code Field Description Values
1.93.89.159 Reversed IP address The IP address of the location that the resulting hostname points to in a reverse order. The actual IP address used in this example is 159.89.93.1 Assigned
.in-addr.arpa Domain The domain name that historically arrived from the times when the Internet was called Arpa. In-addr is an abbreviation for internet address. No other options
PTR Record PTR stands for PTR record and sets up the relationship between IP address and hostname. Stable
cnmcyber.com Hostname The hostname that points to the IP address. Selected
PTR records are needed for outgoing mail servers such as Postfix, because most of the mail providers reject or mark as spam messages received by mail servers without valid reverse dns configuration such as a missing PTR record or mismatch with an A record for the hostname.

SRV record

Main wikipage: SRV record
Any SRV record is a DNS record that specifies the location, both hostname and port number of servers for specific services. SRV is an abbreviation for service. SRV records can be used to direct certain types of traffic to particular servers.

CAA record

Main wikipage: CAA record
Any CAA record is a DNS record that specifies which certificate authorities are permitted to issue certificates for the host. CAA is the acronym for Certification Authority Authorization, which is a method for cross-checking security information on the Internet. CAA records can be used to reduce the risk of unintended certificate mis-issue.

Security threats

Hackers are constantly trying to penetrate DNS primarily because of two reasons. First, DNS is used throughout the whole Internet and, second, the overwhelming majority of host devices utilize the same nameserver software, BIND.

Spoofing

Main wikipage: DNS spoofing
Any DNS spoofing, which is alternatively known as DNS cache poisoning, DNS tampering, DNS hijacking, or DNS redirection, is the attack against the DNS protocol that aims to alternate IP addresses cached by DNS resolvers for a DNS record of the attacker choice.
In order to increase speed of DNS resolutions for the end user, as well as to decrease costs for Internet service providers (ISP), they usually configure their nameservers to cache DNS responses for the period defined in the TTL value of the requested record set. This allows for all concurrent requests to be served from the local cache at the ISP and not require the series of lookups normally required.
This mechanism, however, is the target for the DNS spoofing attacks. In these attacks, the attacker aims legitimate DNS resolvers to have an attacker's IP address cached as a false DNS record. For instance, this false record can be an A record or NS record.
For example, the attacker would send a fake resolutions to legitimate DNS resolver and seek the attacker's IP address to be cached instead of or in addition to the legitimate IP address. The attacker then could display a fake login page and harvest users' logins and passwords. In the Man-In-The-Middle Attack, the attacker would use the harvested logins and passwords to access the legitimate IP address, so the victim would have regular experience working with familiar resource without knowledge that the attacker is between the victim and the legitimate resource.
DNSSEC, SSL certificates and digital signatures are most common tools used to prevent DNS spoofing.

Reflection attack

DNS reflection attacks differ from DNS cache poisoning attacks in that their primary goal is not to compromise the integrity of a DNS resolver's data, but rather to completely flood a system with DNS responses, rendering it unable to respond to legitimate queries. This type of attack is known as a Denial of Service (DoS) attack.
This attack is conducted by a hacker spoofing the sender IP address of a DNS request to mimic that of the victim"s server. When the DNS resolver then replies to the query, the response will go to the victim"s server rather than the hackers. This attack works due to the fact that a small DNS query can actually return a response that is many times larger than the query itself.
Hackers leverage this in order to direct a large amount of network (DNS) traffic at the victim"s machine. This results in the victim machine being unable to accept or respond to legitimate traffic.

DNSSEC

The original DNS protocol was never designed with security in mind; user access to the nascent Internet was tightly controlled and not open to public access.

The Domain Name System Security Extensions (DNSSEC) are an expansion of the DNS protocol aimed at mitigating a number of security issues that have been identified within the DNS since this time. The DNSSEC provides the ability for DNS clients to determine that the DNS response they are receiving actually comes from the server authoritative for the given hostname. This feature is a direct response to the DNS cache poising attacks described above.

Security RRs

DNSSEC is implemented by adding a number of additional records to the DNS zone of a domain. These records are as follows:
Record Function
RRSIG The signature of the DNS resource record set. This record is returned in the response to any DNS query and can be verified by checking against the public key for the domain.
DNSKEY Contains the public key for the domain.
DS The "Delegation Signer" record, used in authenticating the DNSKEY for a domain.
NSEC Used to prove a name does not exist.
NSEC3 An alternative version of the traditional NSEC record also provides proof a name doesn't exist but prevents zonewalking.
NSEC3PARAM Parameter record for use with NSEC3.

Setup process

In order for DNSSEC to be functional in any given DNS request, every authoritative server from the trust anchor (generally the TLD nameservers) all the way down to the domain's nameservers must support DNSSEC and offer signing of record sets. If any of these do not support the extensions, then it is not possible to utilize the benefits of DNSSEC for that query.
In order to sign a DNS zone with DNSSEC, a private and public key pair is generated by the owner. The public key is listed in the DNS zone in the DNSKEY record whilst the private key is stored securely on the authoritative nameserver. Once this is done, the parent domain server is informed that this zone has been signed.
Each record in the zone is now digitally signed with the signature of the record set stored in the RRSIG record. This record is the encrypted hash of the original records value. Sent with the response to every DNS request, this RRSIG records allows the client to determine if the value received is the same as the one sent by the server.
When the client receives the DNS response, it takes the "RRSIG" value, decrypts it with the public key (retrieved from the DNSKEY record) and then compares the result with the hash of the record value received. If these values match, then the record received is identical to the one sent.
The next feature of DNSSEC is the ability to ensure that the server that sent the record and public key is actually the legitimate authoritative nameserver for that domain. This is achieved using the DS record. This DS record stores a digest of the domain's DNS key in the domain's parent zone that is protected by the parent zones "DNSKEY." This configuration then continues in a hierarchical structure up to the DNS root zone. The data for the DNS root zone is treated as a "Trust Anchor."
Using this record, and hierarchical authentication method, it is possible to ensure that the "DNSKEY" received for a domain has not been spoofed by an attacker.

Secured mapping

The DNS request process remains quite similar to the standard process of requesting DNS records, albeit with a few more pieces of data added in order to verify the responses received.
The following is an example workflow and description of a typical DNS request with DNSSEC enabled. Changes from a normal (non DNSSEC enabled) DNS request are in italics.
  1. The user queries their Internet service provider's (ISP's) DNS resolver asking for the IP address for "www.google.com."
  2. The DNS resolver asks the root nameserver where it can find details for "www.google.com," unless it already has the information cached. It also sets the "DNSSEC OK" (DO) bit to signify that it is requesting the DNSSEC records be returned also.
  3. If it is asked, the root nameserver responds that this information is handled by the .com nameserver. It also sends the DS record for the .com zone and RRSIG records for any records returned with the result. The resolver would then validate that the DS record value received from the root nameserver matches the digest of the DNSKEY record value for the .com zone.
  4. The DNS resolver asks the .com nameserver where it can find details for "www.google.com," unless it already has the information cached.
  5. If it is asked, the .com nameserver responds that this information can be found at the nameservers of google.com. It also sends the DS record for the google.com zone and RRSIG records for any records returned with the result. The resolver would then validate that the DS record value received from the .com nameserver matches the digest of the DNSKEY record value for the google.com zone.
  6. The DNS resolver asks the google.com nameservers where it can find details for "www.google.com," unless it already has the information cached.
  7. If it is asked, the google.com nameservers have this information and respond with a DNS record set (RRSET) of all A records configured for "www.google.com." It also sends the RRSIG value for the RRSET that was returned. The ISP"s DNS resolver can then validate that the RRSIG value is indeed the signature of the RRSET that is returned by checking it against the DNSKEY record in the google.com zone. The resolver has now validated that the records themselves have not been tampered with, and also previously validated that the servers that have been involved in receiving the data are trusted by validating the DS records against the associated parent's DNSKEY record.
  8. The ISP"s DNS resolver then sends the A record for "www.google.com" back to the user. The user then knows what IP address to connect to in order to access "www.google.com."

TLD limitations

Unfortunately, not all top level domains currently support DNSSEC. As was previously mentioned, each server in the chain needs to both support DNSSEC as well as have the appropriate records configured in order for DNSSEC to have any effect. As of April 2013, less than a third of all top level domain servers (including ccTLD's) are configured with the appropriate settings to support DNSSEC. Of the 19 globally assigned top level domains, the following do not currently support DNSSEC: • .aero, • .coop • .int • .jobs • .mobi • .name • .pro • .tel • .travel • .xxx

Issues

Propagation

The most common problem encountered with the DNS protocol is the situation known as "DNS Propagation." When a change is made to a DNS zone, this change is not immediately seen by the rest of the world.
The name itself (specifically the "propagation" component) suggests that changes propagate outwards across the Internet away from the server on which the change was made. This is a common misconception: DNS changes do not propagate outwards like ripples. Instead, when a change is made on a DNS zone, the only real automated propagation of that change is to secondary nameservers. Due to the nature of DNS, all DNS queries for a particular domain will follow the hierarchical approach to determining which server has the data for that domain, eventually arriving at the nameserver for the domain.
As the change to the DNS zone has already occurred on the primary nameserver, the updated values are immediately available and are included in all DNS responses made by that server after the change has been made.
Once the change has been made on the primary nameserver, each additional authoritative nameserver will update its stored values the next time it attempts a zone transfer.
The "propagation" effect is actually caused by ISP's DNS resolvers caching the original, now outdated, DNS records and returning that to the end user, rather than the updated value that could be retrieved directly from the domain"s nameservers.
The TTL value assigned to each record indicates to DNS resolvers how long they should cache the values of the retrieved DNS records.
Ideally, if a change were made to a DNS record immediately after it was cached by a DNS resolver, the delay before that resolver retrieved the updated record would be at most the value of that record sets TTL.
While not as common in recent times, not all DNS resolvers adhere to the values contained in the TTL values, with many choosing to implement their own TTL values for cached records (in order to reduce bandwidth use). This is where the "propagation" effect comes from.
In order to reduce the likelihood of a long DNS propagation time, try this:
  1. Ensure that the TTL values of all records are set to a low value (e.g. 300).
  2. Ensure that when changing nameservers both the old and the new nameservers are configured with the same DNS records. This will ensure that regardless of what nameserver the user is directed to, the results they receive will be consistent.

Not found WWW-hostname

Another common issue with DNS configuration is users' experiencing difficulties accessing their website using "www.example.com" rather than just "example.com."
The cause of this issue is actually quite simple to diagnose as well as resolve. The ideal configuration of the DNS zone to allow the "www." hostname to work is as follows:
  1. Ensure that there is an A record for the domain itself. example.com. IN A 192.168.0.1
  2. Next, create a CNAME record for the "www." hostname. www.example.com. IN CNAME example.com.
The above steps will (as far as DNS is concerned) ensure that the website is visible on both "www.example.com" as well as "example.com." It is then the responsibility of the web server to determine whether to force redirect the user to one or the other. There are other methods to solve this issue, including adding an A record for both the domain itself as well as the "www." hostname (instead of a CNAME record); however for ease of maintenance, the use of a CNAME record is recommended as if the IP address needs to be changed in future, it only needs to be changed once.

NS redundancy

For most hostname owners, configuring a domain's nameservers is as simple as entering the values given to them by their web hosting company. For example: ns1.webhost.com and ns2.webhost.com
It is important to check, however, that your provider"s nameservers are:
  1. Not located on the same server as the website itself; and
  2. Located in geographically diverse locations.
A large number of providers use the web hosting control panel "cPanel" which by default allows the provider to configure the nameservers, web server and mail server to be located on the same physical server. This means that should the server itself go offline for whatever reason, your website and email are completely offline.
Ideally, you should ensure that your web host has at least its nameservers located on separate physical servers as well as networks to your web server and mail server. This provides a layer of defense in that if the DNS service fails to work on one of your nameservers due to a network or hardware issue, the other nameserver is still able to respond, and the website and mail server will remain unaffected.

Tools

Validation

https://intodns.com/

See also

Related lectures

Retrieved from "https://pravka.bskol.com/w/index.php?title=DNS&oldid=109558"