DNS

DNS is the acronym for Domain Name System. On the Internet, DNS stores both host names and IP addresses together for the purpose of mapping any host name to one or more IP addresses or, vice versa, mapping an IP addresses to its host name.

For instance, a user may request its web browser to display some website, while providing this browser with some 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.

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.

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 176.056.230.964 of the host device with some human-readable, human-recognizable domain name such as wiki.ksacerts.com that may contain not necessarily just digits and computer symbols, but also letters, words, or some combinations of those.

Domain names

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 domain name; these two terms can be used interchangeably. The host name is the central part of any URL.

Right-to-left label hierarchy

Every 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 domain name, wiki.ksacerts.com:

Domain name	wiki	.	ksacerts	.	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 host name, some combination of labels shall be associated with one or more IP addresses 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 (.);
• No host name 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 host name is up to 24 characters.

If the domain name is completely specified, including a top-level domain of the Internet, then the host name is said to be a fully qualified domain name (FQDN).

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.

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:

• DNS resolvers moderate any process of translating (resolving) human readable host names into IP addresses that are used in communication between Internet hosts. DNS resolvers cache some data and request the data that they haven't cached from other servers.
• Root nameservers redirect requests to TLD nameservers based on the data for TLD nameservers that root nameservers handle;
• TLD nameservers redirect requests to host nameservers based on the data for host nameservers that TLD nameservers handle.
• Host nameservers handle all data for IP addresses and other DNS records for everything beyond the top-level domains.

Functions

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

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

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 file. Because users can commonly access and host administrators can administer only that data, DNS zone commonly refers to this type of areas	Host NS

DNS 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 domain name 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 host names into IP addresses that are used in communication between Internet hosts. DNS resolvers receive requests in the form of a host name 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.

The complete name-to-IP-address process can be described in the following way:

1. When the user enters a domain name into a web browser, this browser queries their Internet Service Provider's (ISP) DNS resolver asking for the IP address.
2. The DNS resolver asks the root nameserver where it can find details for that domain name, 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 domain name, 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 domain name.
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.

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 host names 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 host names 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 data related to top level domains (TLD) such as .com, .org, and .net.

Host servers

Main wikipage: Host nameserver

In the example given above, we can see that nameservers play a key role in the DNS request process. When you register a new domain name,

the nameservers for that domain are one of the first items you may configure. This is normally done through the same company with which you registered your domain name. Nameserver configuration page at Godaddy.com Configuring the nameservers provides the parent domains (e.g. .com) with an address at which the rest of the records for that domain name can be found. As was seen in step 5 above, these details are given by the TLD nameservers whenever they are queried by a DNS resolver.

regarding a domain name (IP addresses, host names and aliases, mail server details, etc.) are stored on the configured host nameservers in what is known as DNS zones. These zones are generally bundled into a zone file, which contains details of all domains for which the given nameserver is authoritative. 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)

Requests

Main wikipage: DNS request

A DNS request is a query to obtain DNS records for a particular host device in some network. Используемые порты По стандарту RFC 1035 все DNS-серверы отвечают на порту 53 TCP и UDP. Ранние версии BIND использовали 53 порт так же и при отправке исходящих запросов, более новые ведут себя как обычные DNS-клиенты, используя свободные незарегистрированные порты.

Forward request

A forward (direct) request is a DNS request made in order to obtain the IP address based on its host name.

Reverse request

A reverse request is a DNS request made in order to obtain the host name based on its IP address.

Query methods

Any DNS request, either forward or reverse, can be resolved using one or more methods. Indeed, the resolution process may combine various methods, which may be used simultaneously..

Некоторые серверы поддерживают возможность работать в разных режимах для разных сегментов сети. В Bind этот режим называется view. Например, сервер может для локальных адресов (например, 10.0.0.0/8) отдавать локальные адреса серверов, для пользователей внешней сети — внешние адреса. Так же сервер может быть авторитативным для заданной зоны только для указанного диапазона адресов (например, в сети 10.0.0.0/8 сервер объявляет себя авторитативным за зону internal, при этом для внешних адресов в ответ на запрос имени из зоны internal будет отдаваться ответ «неизвестен»).

Recursive query

Рекурсивный запрос

Рекурсивный запрос предполагает получение окончательного ответа от сервера, к которому он направлен. Рекурсию выполняет сервер.

In a recursive query, a DNS resolver queries a single DNS server, which may in turn query other DNS servers on behalf of the requester. For example, a simple stub resolver running on a home router typically makes a recursive query to the DNS server run by the user's ISP. A recursive query is one for which the DNS server answers the query completely by querying other name servers as needed. In typical operation, a client issues a recursive query to a caching recursive DNS server, which subsequently issues non-recursive queries to determine the answer and send a single answer back to the client. The resolver, or another DNS server acting recursively on behalf of the resolver, negotiates use of recursive service using bits in the query headers. DNS servers are not required to support recursive queries.

Non-recursive query

In a non-recursive query, a DNS resolver queries a DNS server that provides a record either for which the server is authoritative, or it provides a partial result without querying other servers. In case of a caching DNS resolver, the non-recursive query of its local DNS cache delivers a result and reduces the load on upstream DNS servers by caching DNS resource records for a period of time after an initial response from upstream DNS servers.

Iterative query

Итеративный запрос предполагает (допускает) выполнение рекурсии клиентом.

The iterative query procedure is a process in which a DNS resolver queries a chain of one or more DNS servers. Each server refers the client to the next server in the chain, until the current server can fully resolve the request. For example, a possible resolution of www.example.com would query a global root server, then a "com" server, and finally an "example.com" server.

Records

While being initially created as some name-to-IP address mapping database, DNS also allows for critical properties to be assigned to a domain name. This properties include associated email addresses, anti-spam information, etc. and are stored in DNS records.

Each piece of data stored within a zone file is called a resource record. There are a large number of different record types that can exist for a domain. The most common record types are as follows:

SOA record

The DNS "SOA" record is a mandatory entry for any DNS zone. It is the "Start of Authority" record; its purpose is to inform DNS resolvers that this server is the authoritative server for the requested domain name. The structure of an SOA record is as follows: @ 14400 IN SOA ns1.example.com. admin.example.com. (

           2012121902 ; serial number
           3600; refresh seconds
           600; retry seconds
           86400; expire seconds
           3600; minimum TTL seconds       );

The first entry in the "SOA" record contains the name of the host where the zone file is located (ns1.example.com above) as well as the 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

"A" records are one of the key record types within the DNS. Their purpose is to define a relationship between a human-friendly name and an IPv4 address. These records are useful for pointing different portions of your domain to different IP addresses (e.g. pointing "www.example.com" to your web server). Each DNS "A" record consists of both a host name and IP address. The format of these records is as follows: <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

"AAAA" records are similar to DNS "A" records.The only difference is 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

"NS" records are used to specify what the nameservers for the domain name are. These should ideally match the values set at the domain name registrar.

Each DNS "NS" record consists of both the 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 domain name registrar, it can lead to problems accessing your website in certain circumstances.

CNAME record

"CNAME" is short for canonical name. These records are used to define 

an alias for another domain or host name. These records are particularly useful when you have multiple host names that are located on the same IP address. Each "CNAME" record needs to point to another valid host name, either 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" is short for Mail Exchanger. These records are used to identify the 

server that handles email address for your domain name. Each "MX" record contains three pieces of information: the host name, the priority and the mail server"s host name. The format of an "MX" record is as follows: <HOSTNAME> IN MX <PRIORITY><MAIL SERVER HOSTNAME> The host name value is the domain for which the MX record exists. This is generally set to the value of your domain name (e.g. "example.com."). The priority value is a numerical value that signifies the priority of this 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 the value of the priority field, the higher the priority of the mail server. The mail server host name is then the host name that handles email for 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 to "mail.example.com". If this is the case, it is important to ensure that a valid DNS "A" record exists for the "mail" host name. If this isn"t configured properly, you may experience issues receiving email at your domain.

TXT record

"TXT" (or text) records serve multiple purposes. They allow for virtually 

any free text to be stored and can be assigned to specific host names. The typical format for a TXT record is as follows:

<HOSTNAME> IN TXT <TEXT DATA>
 "TXT" records often store sender policy framework (SPF) data . SPF data 

is used to inform email servers which actual systems are authorized to send mail on behalf of the given host name. This is useful in the 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

The "PTR" record type is used to perform the exact opposite functionality of the DNS "A" record. Where the "A" record allows for the translation of a host name into an IP address, the "PTR" record allows for an IP address to be translated into a domain name. The format of a "PTR" record is as follows: <IP REVERSED>.in-addr.arpa PTR <DOMAIN> The first field is the IP address in reverse format, with the "in-addr.arpa" value appended to the end, for example "1.0.168.192.in-addr.arpa". The domain value would then be the domain name you want the IP address (192.168.0.1 in this example) to resolve to. Ensuring that both forward lookups (using "A" records) and reverse lookups (using "PTR" records) match is important: in some instances, applications will not work correctly if this is not configured correctly. For example, some mail servers will not accept mail from a mail server if the reverse lookup does not match the domain name the email is originating from. SECURITY ISSUES As DNS is one of the core technologies used in the delivery of the modern Internet, coupled with the high percentage of nameservers using the same nameserver software (BIND), the DNS protocol and servers implementing it are under constant scrutiny from hackers. The following are two common DNS related attacks: DNS CACHE POISONING One of the more common attacks against the DNS protocol is the DNS cache poisoning attack. In order to reduce unnecessary Internet traffic, most Internet Service Providers (ISP) 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 results in faster DNS responses for the end user, as well as a decrease in data costs for the ISP. 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 the ISP"s DNS resolvers for a record of their choosing. For example, the attacker would seek to have the IP address of the 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 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 the legitimate server. Once this is achieved, the hacker could potentially display a fake login page and harvest users" logins and passwords. DNS REFLECTION ATTACKS 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. DZONE.COM/REFCARDZ 7 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 domain name. This feature is a direct response to the DNS cache poising attacks described above. HOW DNSSEC WORKS DNSSEC is implemented by adding a number of additional records to the DNS zone of a domain. These records are as follows: RECORD NAME 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. In order for DNSSEC to be functional in any given DNS query, 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. 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 query, 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 domain server 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. DNS REQUEST PROCESS WITH DNSSEC The DNS request process remains quite similar to the standard process of requesting DNS data, 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 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 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 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 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. 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.