19
DNS stands for “Domain Name System” and helps resolving domain names to IP numbers as it is much easier for people to remember logical names rather then a 12 digit number. DNS uses 3 major components”Resolvers (client)”, “Name Servers” and “Domain Name Space”. In basic DNS communication a client (Resolver) sends a query to a Name Server, which returns with the requested information or an address for another Name Server, an error message is received if the query gives no results.
Think of DNS as a global telephone book that computers know how to access. But instead of matching names to phone numbers, the global DNS keeps matches computer hostnames to IP addresses. This allows you to type a name such as www.google.com into your web browser and make a connection to the IP address 72.14.203.104.
It’s important to ensure that the global DNS contains accurate information and that it avoids duplicate IP addresses or hostnames. This is the job of Internet Corporation for Assigned Names and Numbers (ICANN).
DNS SERVERS/ NAME SERVERS:
DNS servers/ Name Servers are the computers that run DNS server programs containing DNS database information about the DNS domain tree structure. These servers, which may be either dedicated devices or software processes running on machines store and manage information about domains, and respond to resolution requests for clients.
DNS servers also attempt to resolve client queries. When queried, DNS servers can provide the requested information, provide a pointer to another server that can help resolve the query, or respond that it does not have the information or that the information does not exist.
Name servers that hold all information on hosts within a zone are called authoritative for this zone, and are sometimes referred to as master name servers. While the DNS is a global database, its contents have been distributed using a hierarchical format. The format looks like this:
Root . Top level domain . Second level domain . Hostname
When you compare that format to a Fully Qualified Domain Name (FQDN) it appears backwards. For example, in the FQDN www.google.com:
- www is the hostname
- google is the second level domain (SLD)
- com is the top level domain (TLD)
While resolving that FDQN to find its IP address, DNS will:
- query a root DNS server to find the IP address of the DNS server hosting the com portion of the database
- query the com DNS server to find the IP addresss of the DNS server hosting the google portion of the database
- query the google DNS server to find the IP address associated with the host named www
The list of DNS root servers can be found at root-servers.org; all DNS servers contain a copy of the file listing the root servers.
The DNS protocol uses port 53 for communications. Interestingly, it uses both the UDP and TCP transports. As a general rule of thumb:
- UDP is used when an FQDN needs to be resolved into an IP address
- TCP is used by the DNS servers within a zone to make sure they all have the most recent copy of the zone file; if a DNS server has an out-dated version, it will request a zone transfer over TCP 53
- Occasionally the information needed to resolve an IP address is too large to ship in a UDP packet and is sent in a TCP packet instead
When configuring a firewall, UDP 53 has to be left open so FQDNs can be resolved to IP ddresses. However, many administrators block TCP 53 entirely or restrict it to the IP ddresses of that zone’s DNS servers.
ZONE AND RESOURCE RECORDS:
The SLD, or the middle part of a FQDN, is the portion that is purchased from a Registrar. For example, Google had to purchase and register the google name. (You can see who urchased the name and when by querying WHOIS—see the WHOIS article for details). When a name is registered, the Registrar is responsible for adding the new entry to the TLD database. In other words, when google was registered, the Registrar added an entry to the com database pointing to the address of the google DNS server.
Once an SLD is registered, the registrant becomes responsible for maintaining that portion of the DNS database and it will contain the DNS entries for the hosts belonging to the SLD. That area of responsibility is known as a DNS zone which is why you’ll often see DNS configuration files referred to as zone files.
When configuring the zone, the DNS administrator adds entries describing the hosts that need to be found via DNS. These entries are known as resource records as they describe the type of resource. For example, an A resource record matches an IP address to a hostname, an MX resource record indicates that the host is a mail server for the domain, and an NS record indicates that the host is a DNS server for the domain.
HOW DNS RESOLUTION WORKS:
Suppose your computer wants to find the IP address of network-surveys.cr.yp.to. It contacts a series of DNS servers around the Internet.
There are several DNS servers with information about network-surveys.cr.yp.to. A central root server has the following data in a file on disk:
The root server’s IP address is 198.41.0.4; your computer also has this address as a DNS resolver in a file on disk. Your computer sends its question to the root server, and receives a response from the root server’s data:
The response &to:198.6.1.82 is a delegation. It says “For information about .to, ask the DNS server at IP address 198.6.1.82.”
The DNS server at 198.6.1.82 has the following data in a file on disk:
Your computer sends its question to that DNS server, and receives a response:
The response &yp.to:131.193.178.160 is another delegation. It says “For information about .yp.to, ask the DNS server at IP address 131.193.178.160.”
The DNS server at 131.193.178.160 has the following data in a file on disk:
Your computer sends its question to that DNS server, and receives a response:
The response =network-surveys.cr.yp.to:131.193.178.100 finally answers the original question: the IP address of network-surveys.cr.yp.to is 131.193.178.100.All of this work is handled by a DNS cache running on your computer. Your computer remembers everything that it learned (for a limited amount of time; information changes!) to save time later. As an alternative, your computer can contact an external DNS cache operated by your Internet service provider; the external DNS cache will do all the work and report the answer.
REVERSE DNS AND PTR RECORDS:
Reverse DNS turns an IP address into a hostname — for example, it might turn 192.0.2.25 into host.example.com.
For your domains, standard DNS (turning a hostname into an IP address, such turning host.example.com into 192.0.2.25) starts with the company (registrar) that you registered your domains with. You let them know what DNS servers are responsible for your domain names, and the registrar sends this information to the root servers (technically, the parent servers for your TLD). Then, anyone in the world can access your domains, and you can send them to any IP addresses you want. You have full control over your domains, and can send people to any IPs (whether or not you have control over that IPs, although you should have permission to send them to IPs that is not yours).
Reverse DNS works in a similar method. For your IPs, reverse DNS (turning 192.0.2.25 back into host.example.com) starts with your ISP (or whoever told you what your IP addresses are). You let them know what DNS servers are responsible for the reverse DNS entries for your IPs (or, they can enter the reverse DNS entries on their DNS servers), and your ISP gives this information out when their DNS servers get queried for your reverse DNS entries. Then, anyone in the world can look up the reverse DNS entries for your Imps, and you can return any hostnames you want (whether or not you have control over those domains, although you should have permission to point them to hostnames that are not on your domains).
So for both standard DNS and reverse DNS, there are two steps: [1] You need DNS servers, and [2] You need to tell the right company (your registrar for standard DNS lookups, or your ISP for reverse DNS lookups) where your DNS servers are located. Without Step 2, nobody will be able to reach your DNS servers. If you can comprehend the above paragraphs (which takes some time), you’ll understand the biggest problem that people have with reverse DNS entries. The biggest problem people have is that they have DNS servers that work fine with their domains (standard DNS), they add reverse DNS entries to those servers, and it doesn’t work. If you understand the above paragraphs, you’ll see the problem: If your ISP doesn’t know that you have DNS servers to handle the reverse DNS for your IPs, they won’t send that information to the root servers, and nobody will even get to your DNS servers for reverse DNS lookups.
BASIC CONCEPTS OF REVERSE DNS:
- Reverse DNS turns 192.0.2.25 into host.example.com (an IP address into a host name).
- Typical reverse DNS lookup path: DNS resolver => root servers => ARIN (North American IP registry) => Local ISP => Acme Inc. DNS servers.
- Whoever supplies your IP addresses (usually your ISP) MUST either [1] set up your reverse DNS entries on their DNS servers, or [2] “delegate authority” for your reverse DNS entries to your DNS servers.
- Reverse DNS entries use a host name with a reversed IP address with “.in-addr.arpa” added to it — for example, “25.2.0.192.in-addr.arpa” (“.ip6.arpa” is used for IPv6 reverseDNS lookups).
- Reverse DNS entries are set up with PTR records (whereas standard DNS uses A records), which look like “25.2.0.192.in-addr.arpa. PTR host.example.com” (whereasstandard DNS would look like “host.example.com. A 192.0.2.25″).
- All Internet hosts should have a reverse DNS entry (see RFC1912 section 2.1).
- Mail servers with no reverse DNS will have a hard time getting mail to certain large ISPs.
VERY COMMON MYTH:
- Myth: If you have a reverse DNS entry listed in your DNS server, you have reverse DNS properly set up.
- Fact: This is often not the case.
You need TWO things in order to have your DNS set up properly:
- Your DNS servers (or your ISP’s) MUST have the reverse DNS entries set up (“25.2.0.192.in-addr.arpa. PTR host.example.com”).
- Your ISP or bandwidth provider MUST set up the reverse DNS on their end, so that DNS resolvers around the world will know that your DNS servers are the ones to go to when looking up the reverse DNS for your IP addresses.
HOW A REVERSE DNS LOOKUP IS ACCOMPLISHED:
- The DNS resolver reverses the IP, and adds it to “.in-addr.arpa” (or “.ip6.arpa” for IPv6 lookups), turning 192.0.2.25 into 25.2.0.192.in-addr.arpa.
- The DNS resolver then looks up the PTR record for 25.2.0.192.in-addr.arpa.
- The DNS resolver checks asks the root servers for the PTR record for 25.2.0.192.in-addr.arpa.
- The root servers refer the DNS resolver to the DNS servers in charge of the Class A range (192.in-addr.arpa, which covers all IPs that begin with 192).
- In almost all cases, the root servers will refer the DNS resolver to a “RIR”(“Regional Internet Registry”). These are the organizations that allocate IPs. In general, ARIN handles North American IPs, APNIC handles Asian-Pacific IPs, and RIPE handles European IPs.
- The DNS resolver will ask the ARIN DNS servers for the PTR record for 25.2.0.192.in-addr.arpa.
- The ARIN DNS servers will refer the DNS resolver to the DNS servers of the organization that was originally given the IP range. These are usually the DNS servers of your ISP, or their bandwidth provider.
- The DNS resolver will ask the ISP’s DNS servers for the PTR record for 25.2.0.192.in-addr.arpa.
- The ISP’s DNS servers will refer the DNS resolver to the organization’s DNS servers.
- The DNS resolver will ask the organization’s DNS servers for the PTR record for 25.2.0.192.in-addr.arpa.
- The organization’s DNS servers will respond with “host.example.com”.
SAMPLE ZONE FILE:
The following example shows a very basic zone file.
$ORIGIN example.com
$TTL 86400
@ IN SOA ns1.example.net. hostmaster.example.com. (
2008021901 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
example.com. IN MX 10 mail.example.com.
example.com. IN MX 20 mail2.example.com.
example.com. IN A 10.0.1.5
server IN A 10.0.1.5
ns1 IN A 10.0.1.2
ns2 IN A 10.0.1.3
ftp IN CNAME example.com.
mail IN CNAME example.com.
mail2 IN CNAME example.com.
www IN CNAME example.com.
TYPES OF DNS RECORDS:
There are many types of records that can be used in DNS. Here are the most common.
A records – address data
An A record is used to map a hostname to an IP address. This example shows that the IP for mail.example.com is 192.0.2.3
mail.example.com. IN A 192.0.2.3
MX records – mail exchange information
MX records indicate which server or servers are responsible for handling mail for the domain. A numerical priority determines the order in which servers should be used. The server with the lowest priority is the primary. In this example, mail.example.com handles mail, but mail2.example.com will also accept mail if the primary is down:
example.com. IN MX 10 mail.example.com.
example.com. IN MX 100 mail2.example.com.
NS records – delegation information
NS records indicate which nameservers are responsible for the domain. In this example, the domain is delegated to example.net nameservers:
example.com. IN NS ns1.example.net.
example.com. IN NS ns2.example.net.
CNAME records – make an alias
If you want a hostname to be an alias for some other domain, you can give it a CNAME record to indicate the real domain that it is aliasing. In this example, server.example.com is the real domain name, but ftp.example.com is an alias for it that can also be used:
ftp.example.com. IN CNAME server.example.com.
PTR records – reverse DNS data
Whereas A records map hostnames to IP addresses, PTR records make it possible to start with an IP address and discover which hostname points to it. In this example, 192.0.2.3 maps back to mail.examnple.com, so it matches the A record above:
3.2.0.192.in-addr.arpa. IN PTR mail.example.com.
Note that the IP address is inversed and prepended to “in-addr.arpa.” to make it fit into the DNS.
TXT Record
A TXT Record allows an administrator to insert arbitrary text into a DNS record. For example, this record is used to implement the Sender Policy Framework and Domain Keys specifications.
example.com. IN TXT “v=spf1 a ~all”
Wildcard DNS record
A zone record that will match all requests for non-existent domain names, i.e. domain names for which there are no records at all.
*.example.com. IN A 192.0.2.3
This will make anything.example.com to resolve to 192.0.2.3 IP
ZONE FILE DIRECTIVES:
The following example shows the basic structure of an SOA record:
$ORIGIN <domain.com>
$TTL <TTL Value>
@ IN SOA <primary-name-server> <hostmaster-email> (
<serial-number>
<time-to-refresh>
<time-to-retry>
<time-to-expire>
<minimum-TTL> )
$TTL — Sets the default Time to Live (TTL) value for the zone. This is the length of time, in seconds; a zone resource record is valid. Each resource record can contain its own TTL value, which overrides this directive.
SOA — Start Of Authority record, proclaims important authoritative information about a namespace to the nameserver.
The @ symbol places the $ORIGIN directive (or the zone’s name, if the $ORIGIN directive is not set) as the namespace being defined by this SOA resource record. The primary nameserver that is authoritative for this domain is used for the <primary-name-server>, and the email of the person to contact about this namespace is substituted for the
<hostmaster-email>.
The <serial-number> is incremented every time you change the zone file so that named will know that it should reload this zone. The <time-to-refresh> tells any slave servers how long to wait before asking the master nameserver if any changes have been made to the zone. The <serial-number> value is used by the slave to determine if it is using outdated zone data and should refresh it.
The <time-to-retry> tells the slave nameserver the interval to wait before issuing another refresh request, if the master nameserver is not answering. If the master has not replied to a refresh request before the <time-to-expire> elapses, the slave stops responding as an authority for requests concerning that namespace.
The <minimum-TTL> requests that other nameservers cache the zone’s information for at least this amount of time (in seconds).
DNS PROGRAMS:
1) BIND
Berkeley Internet Name Domain (BIND) is one of the most popular and commonly used DNS program. BIND performs name resolution services through the /usr/sbin/named daemon. BIND also includes an administration utility called /usr/sbin/rndc. BIND stores its configuration files in the following two places:
• /etc/named.conf — The configuration file for the named daemon.
• /var/named/ directory — The named working directory which stores zone, statistic, and cache files.
The /etc/named.conf file is a collection of statements using nested options surrounded by opening and closing ellipse characters, { }.
A typical named.conf file is organized similar to the following example:
<statement-1> ["<statement-1-name>"] [<statement-1-class>] {
<option-1>;
<option-2>;
<option-N>;
};
<statement-2> ["<statement-2-name>"] [<statement-2-class>] {
<option-1>;
<option-2>;
<option-N>;
};
<statement-N> ["<statement-N-name>"] [<statement-N-class>] {
<option-1>;
<option-2>;
<option-N>;
};
A zone statement defines the characteristics of a zone such as the location of its configuration file and zone-specific options. This statement can be used to override the global options statements.
A zone statement takes the following form:
zone <zone-name> <zone-class> {
<zone-options>;
[<zone-options>; ...]
};
The other commonly used DNS programs are:
2) Djbdns
