DNS

It is an Internet service to translate domain names into IP addresses as, domain names are alphabetic, they’re easy to remember but internet is based on IP addresses. A DNS service translates the name into the corresponding IP address like, the domain name www.example.com might translate to 198.105.232.4. The DNS system is an network as, if one DNS server doesn’t know how to translate a particular domain name, it asks another one, and so on, until the correct IP address is returned.

A DNS lookup can be bypassed by giving IP address instead of domain name. DNS works in an complex and hierarchical manner. After connecting the PC or network node to Internet service provider (ISP) or WiFi network, the modem or router assigns a network address to node and sends network configuration about one or more DNS servers to use.

DNS identifies by domain names that are organized as a tree or in hierarchical manner according to organizational or administrative boundaries. Each node of the tree, called a domain, is given a label. The domain name of the node is the concatenation of all the labels on the path from the node to the root node like network.support.vskills.in

• vskills.in is the domain name.
• . is the root domain
• in is the top level domain
• vskills is the second-level domain
• support is a subdomain of vskills
• network is the hostname

For administrative purpose, domain name space is divided into DNS zones, each starting at a node and extending down to the leaf node or to nodes where other zones start. A DNS zone is a portion of the global DNS name space for which administrative responsibility has been delegated. The data for each zone is stored in a name server, which answers queries about the zone using the DNS protocol. A zone and a domain are different as a zone consists of discrete or contiguous portion of the domain tree, which can map exactly to a single domain or include only part of a domain. On the other hand, every node in the DNS tree is a domain, even if it has no subdomains. Any computer registered to join the Domain Name System can act as a DNS server. A DNS server contains a database of network names and address for other Internet hosts. DNS servers are organized in a hierarchy structure. At its top level, the root zone or root domain “.” is administered by a set of 13 root nameserver clusters distributed throughout the world. DNS protocol use both TCP and UDP ports — port 53/tcp and port 53/udp.

The Name Resolution process is done as

• Upon receiving query from client, the local nameserver will check if it has the authority for the required domain name. If it has, the local nameserver returns the IP address sought. Otherwise, go to step 2.
• Query one of the root nameservers to find the server authoritative for the next level down.
• Querying this second nameserver for the address of a DNS server with detailed knowledge of the second-level domain.
• Repeating the previous step to progress down the name, until the final step which would, rather than generating the address of the next DNS server, return the final address sought.

DNS Terms

• Zone – The domain namespace is divided into regions called zones. For instance, if you have example.com, you have the example section (or zone) of the com domain.
• DNS server – The DNS server is a server that maintains the name and IP information for a do-
• You can have a primary DNS server for master zone, a secondary server for slave zone, or a slave server without any zones for caching.
• Master zone DNS server – The master zone includes all hosts from your network and a DNS server master zone stores up-to-date records for all the hosts in your domain.
• Slave zone DNS server – A slave zone is a copy of the master zone. The slave zone DNS server obtains its zone data with zone transfer operations from its master server. The slave zone DNS server responds authoritatively for the zone as long as it has valid (not expired) zone data. If the slave cannot obtain a new copy of the zone data, it stops responding for the zone.
• Forwarder – Forwarders are DNS servers to which your DNS server should send queries it cannot answer. To enable different configuration sources in one configuration, netconfig is used.
• Record – The record is information about name and IP address. Supported records and their syntax are described in BIND documentation. Some special records are:
• NS record – An NS record tells name servers which machines are in charge of a given do-
• main zone.
• MX record – The MX (mail exchange) records describe the machines to contact for directing mail across the Internet.
• SOA record – SOA (Start of Authority) record is the first record in a zone file. The SOA record is used when using DNS to synchronize data between multiple computers.

DNS is usually implemented using one or more centralized servers that are authoritative for certain domains. When a client host requests information from a nameserver, it usually connects to port 53. The nameserver then attempts to resolve the name requested. If it does not have an authoritative answer, or does not already have the answer cached from an earlier query, it queries other nameservers, called root nameservers, to determine which nameservers are authoritative for the name in question, and then queries them to get the requested name.

Nameserver Zones – In a DNS server such as BIND, all information is stored in basic data elements called resource records (RR). The resource record is usually a fully qualified domain name (FQDN) of a host, and is broken down into multiple sections organized into a tree-like hierarchy. This hierarchy consists of a main trunk, primary branches, secondary branches, and so on. The following is an example of a resource record – bob.sales.example.com.

Each level of the hierarchy is divided by a period (that is, .). In the example above, com defines the top-level domain, example its subdomain, and sales the subdomain of example. In this case, bob identifies a resource record that is part of the sales.example.com domain. With the exception of the part furthest to the left (that is, bob), each of these sections is called a zone and defines a specific namespace.

Zones are defined on authoritative nameservers through the use of zone files, which contain definitions of the resource records in each zone. Zone files are stored on primary nameservers (also called master nameservers), where changes are made to the files, and secondary nameservers (also called slave nameservers), which receive zone definitions from the primary nameservers. Both primary and secondary nameservers are authoritative for the zone and look the same to clients. Depending on the configuration, any nameserver can also serve as a primary or secondary server for multiple zones at the same time.

There are two nameserver configuration types:

• Authoritative – Authoritative nameservers answer to resource records that are part of their zones only. This category includes both primary (master) and secondary (slave) nameservers.
• Recursive – Recursive nameservers offer resolution services, but they are not authoritative for any zone. Answers for all resolutions are cached in a memory for a fixed period of time, which is specified by the retrieved resource record.

Although a nameserver can be both authoritative and recursive at the same time, it is recommended not to combine the configuration types. To be able to perform their work, authoritative servers should be available to all clients all the time. On the other hand, since the recursive lookup takes far more time than authoritative responses, recursive servers should be available to a restricted number of clients only, otherwise they are prone to distributed denial of service (DDoS) attacks.

BIND as a Nameserver

BIND consists of a set of DNS-related programs. It contains a monolithic nameserver called named, an administration utility called rndc, and a debugging tool called dig.

When the named service is started, it reads the configuration from the files as

Path	Description
/etc/named.conf	The main configuration file.
/etc/named/	An auxiliary directory for configuration files that are included in the main configuration file.

The configuration file consists of a collection of statements with nested options surrounded by opening and closing curly brackets (that is, { and }). Note that when editing the file, you have to be careful not to make any syntax error, otherwise the named service will not start. A typical /etc/named.conf file is organized as

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;

};

Common Statement Types

The following types of statements are commonly used in /etc/named.conf

acl – The acl (Access Control List) statement allows you to define groups of hosts, so that they can be permitted or denied access to the nameserver. It takes the following form:

acl acl-name {

match-element;

…

};

The acl-name statement name is the name of the access control list, and the match-element option is usually an individual IP address (such as 10.0.1.1) or a CIDR network notation (for example, 10.0.1.0/24). A list of already defined keywords

Keyword	Description
any	Matches every IP address.
localhost	Matches any IP address that is in use by the local system.
localnets	Matches any IP address on any network to which the local system is connected.
none	Does not match any IP address.

The acl statement can be especially useful with conjunction with other statements such as options.

include – The include statement allows you to include files in the /etc/named.conf, so that potentially sensitive data can be placed in a separate file with restricted permissions. It takes the following form:

include “file-name”

The file-name statement name is an absolute path to a file.

include “/etc/named.rfc1912.zones”;

options – The options statement allows you to define global server configuration options as well as to set defaults for other statements. It can be used to specify the location of the named working directory, the types of queries allowed, and much more. It takes the following form:

options {

option;

…

};

Option	Description
allow-query	Specifies which hosts are allowed to query the nameserver for authoritative resource records. It accepts an access control lists, a collection of IP addresses, or networks in the CIDR notation. All hosts are allowed by default.
allow-query-cache	Specifies which hosts are allowed to query the nameserver for non-authoritative data such as recursive queries. Only localhost and localnets are allowed by default.
blackhole	Specifies which hosts are not allowed to query the nameserver. This option should be used when particular host or network floods the server with requests. The default option is none.
directory	Specifies a working directory for the named service. The default option is /var/named/.
dnssec-enable	Specifies whether to return DNSSEC related resource records. The default option is yes.
dnssec-validation	Specifies whether to prove that resource records are authentic via DNSSEC. The default option is yes.
forwarders	Specifies a list of valid IP addresses for nameservers to which the requests should be forwarded for resolution.
forward	Specifies the behavior of the forwarders directive. It accepts the following options: ü   first — The server will query the nameservers listed in the forwarders directive before attempting to resolve the name on its own. ü   only — When unable to query the nameservers listed in the forwarders directive, the server will not attempt to resolve the name on its own.
listen-on	Specifies the IPv4 network interface on which to listen for queries. On a DNS server that also acts as a gateway, you can use this option to answer queries originating from a single network only. All IPv4 interfaces are used by default.
listen-on-v6	Specifies the IPv6 network interface on which to listen for queries. On a DNS server that also acts as a gateway, you can use this option to answer queries originating from a single network only. All IPv6 interfaces are used by default.
max-cache-size	Specifies the maximum amount of memory to be used for server caches. When the limit is reached, the server causes records to expire prematurely so that the limit is not exceeded. In a server with multiple views, the limit applies separately to the cache of each view. The default option is 32M.
notify	Specifies whether to notify the secondary nameservers when a zone is updated. It accepts the following options: ü   yes — The server will notify all secondary nameservers. ü   no — The server will not notify any secondary nameserver. ü   master-only — The server will notify primary server for the zone only. ü   explicit — The server will notify only the secondary servers that are specified in the also-notify list within a zone statement.
pid-file	Specifies the location of the process ID file created by the named service.
recursion	Specifies whether to act as a recursive server. The default option is yes.
statistics-file	Specifies an alternate location for statistics files. The /var/named/ named.stats file is used by default.

Example of options usage

options {

allow-query { localhost; };

listen-on port 53 { 127.0.0.1; };

listen-on-v6 port 53 { ::1; };

max-cache-size 256M;

directory “/var/named”;

statistics-file “/var/named/data/named_stats.txt”;

recursion yes;

dnssec-enable yes;

dnssec-validation yes;

};

zone – The zone statement allows you to define the characteristics of a zone, such as the location of its configuration file and zone-specific options, and can be used to override the global options statements. It takes the following form:

zone zone-name [zone-class] {

option;

…

};

The zone-name attribute is the name of the zone, zone-class is the optional class of the zone, and option is a zone statement option as described in table above.

The zone-name attribute is particularly important, as it is the default value assigned for the $ORIGIN directive used within the corresponding zone file located in the /var/named/ directory. The named daemon appends the name of the zone to any non-fully qualified domain name listed in the zone file. For example, if a zone statement defines the namespace for example.com, use example.com as the zone-name so that it is placed at the end of hostnames within the example.com zone file.

Option	Description
allow-query	Specifies which clients are allowed to request information about this zone. This option overrides global allow-query option. All query requests are allowed by default.
allow-transfer	Specifies which secondary servers are allowed to request a transfer of the zone’s information. All transfer requests are allowed by default.
allow-update	Specifies which hosts are allowed to dynamically update information in their zone. The default option is to deny all dynamic update requests.
file	Specifies the name of the file in the named working directory that contains the zone’s configuration data.
masters	Specifies from which IP addresses to request authoritative zone information. This option is used only if the zone is defined as type slave.
notify	Specifies whether to notify the secondary nameservers when a zone is updated. It accepts the following options: ü   yes — The server will notify all secondary nameservers. ü   no — The server will not notify any secondary nameserver. ü   master-only — The server will notify primary server for the zone only. ü   explicit — The server will notify only the secondary servers that are specified in the also-notify list within a zone statement.
type	Specifies the zone type. It accepts the following options: delegation-only — Enforces the delegation status of infrastructure zones such as COM, NET, or ORG. Any answer that is received without an explicit or implicit delegation is treated as NXDOMAIN. This option is only applicable in TLDs or root zone files used in recursive or caching implementations. ü   forward — Forwards all requests for information about this zone to other nameservers. ü   hint — A special type of zone used to point to the root nameservers which resolve queries when a zone is not otherwise known. No configuration beyond the default is necessary with a hint zone. ü   master — Designates the nameserver as authoritative for this zone. A zone should be set as the master if the zone’s configuration files reside on the system. ü   slave — Designates the nameserver as a slave server for this zone. Master server is specified in masters directive.

Most changes to the /etc/named.conf file of a primary or secondary nameserver involve adding, modifying, or deleting zone statements, and only a small subset of zone statement options is usually needed for a nameserver to work efficiently.

A secondary server’s zone statement is slightly different. The type is set to slave, and the masters directive is telling named the IP address of the master server.

The following types of statements are less commonly used in /etc/named.conf:

controls – The controls statement allows you to configure various security requirements necessary to use the rndc command to administer the named service.

key – The key statement allows you to define a particular key by name. Keys are used to authenticate various actions, such as secure updates or the use of the rndc command. Two options are used with key

• algorithm algorithm-name — The type of algorithm to be used (for example, hmac-md5).
• secret “key-value” — The encrypted key.

logging – The logging statement allows you to use multiple types of logs, so called channels. By using the channel option within the statement, you can construct a customized type of log with its own file name (file), size limit (size), versioning (version), and level of importance (severity). Once a customized channel is defined, a category option is used to categorize the channel and begin logging when the named service is restarted.

By default, named sends standard messages to the rsyslog daemon, which places them in

/var/log/messages. Several standard channels are built into BIND with various severity

levels, such as default_syslog (which handles informational logging messages) and

default_debug (which specifically handles debugging messages). A default category, called

default, uses the built-in channels to do normal logging without any special configuration.

server – The server statement allows you to specify options that affect how the named service should respond to remote nameservers, especially with regard to notifications and zone transfers. The transfer-format option controls the number of resource records that are sent with each message. It can be either one-answer (only one resource record), or many-answers (multipleresource records). Note that while the many-answers option is more efficient, it is not supported by older versions of BIND.

trusted-keys – The trusted-keys statement allows you to specify assorted public keys used for secure DNS (DNSSEC).

view – The view statement allows you to create special views depending upon which network the host querying the nameserver is on. This allows some hosts to receive one answer regarding a zone

while other hosts receive totally different information. Alternatively, certain zones may only be made available to particular trusted hosts while non-trusted hosts can only make queries for other zones.

Multiple views can be used as long as their names are unique. The match-clients option allows you to specify the IP addresses that apply to a particular view. If the options statement is used within a view, it overrides the already configured global options. Finally, most view statements contain multiple zone statements that apply to the match-clients list.

Comment Tags – Additionally to statements, the /etc/named.conf file can also contain comments. Comments are ignored by the named service, but can prove useful when providing additional information to a user. The following are valid comment tags:

// – Any text after the // characters to the end of the line is considered a comment. For example:

notify yes; // notify all secondary nameservers

# – Any text after the # character to the end of the line is considered a comment. For example:

notify yes; # notify all secondary nameservers

/* and */ – Any block of text enclosed in /* and */ is considered a comment.

zone files – zone files contain information about a namespace. They are stored in the named working directory located in /var/named/ by default, and each zone file is named according to the file option in the zone statement, usually in a way that relates to the domain in question and identifies the file as containing zone data, such as example.com.zone.

Path	Description
/var/named/	The working directory for the named service. The nameserver is not allowed to write to this directory.
/var/named/slaves/	The directory for secondary zones. This directory is writable by the named service.
/var/named/dynamic/	The directory for other files, such as dynamic DNS (DDNS) zones or managed DNSSEC keys. This directory is writable by the named service.
/var/named/data/	The directory for various statistics and debugging files. This directory is writable by the named service.

A zone file consists of directives and resource records. Directives tell the nameserver to perform tasks or apply special settings to the zone, resource records define the parameters of the zone and assign identities to individual hosts. While the directives are optional, the resource records are required in order to provide name service to a zone. All directives and resource records should be entered on individual lines.

Directives begin with the dollar sign character (that is, $) followed by the name of the directive, and

usually appear at the top of the file. The following directives are commonly used in zone files:

• $INCLUDE – The $INCLUDE directive allows you to include another file at the place where it appears, so that other zone settings can be stored in a separate zone file.
• $ORIGIN – The $ORIGIN directive allows you to append the domain name to unqualified records, such as those with the hostname only. Note that the use of this directive is not necessary if the zone is specified in /etc/named.conf, since the zone name is used by default.
• $TTL – The $TTL directive allows you to set the default Time to Live (TTL) value for the zone, that is, how long is a zone record valid. Each resource record can contain its own TTL value, which overrides this directive.

Common Resource Records – The following resource records are commonly used in zone files

• A – The Address record specifies an IP address to be assigned to a name.
• CNAME – The Canonical Name record maps one name to another. Because of this, this type of record is sometimes referred to as an alias record. CNAME records are most commonly used to point to services that use a common naming scheme, such as www for Web servers. CNAME records should not point to other CNAME records. This is mainly to avoid possible infinite loops. CNAME records should not contain other resource record types (such as A, NS, MX, etc.). The
• only exception are DNSSEC related records (that is, RRSIG, NSEC, etc.) when the zone is signed. Other resource record that point to the fully qualified domain name (FQDN) of a host (that is,
• NS, MX, PTR) should not point to a CNAME record.
• MX – The Mail Exchange record specifies where the mail sent to a particular namespace controlled by this zone should go.
• NS – The Nameserver record announces authoritative nameservers for a particular zone.
  PTR – The Pointer record points to another part of the namespace.
• SOA – The Start of Authority record announces important authoritative information about a namespace to the nameserver. Located after the directives, it is the first resource record in a zone file.

The dig utility is a command line tool that allows you to perform DNS lookups and debug a

nameserver configuration. Its typical usage is as follows:

dig [@server] [option…] name type

The process of building a complete DNS server from start to finish for example.org, consists of following steps

• Establish two name servers: ns1.example.org and ns2.example.org.
• The name servers will be able to respond to queries for IPv6 records that they know about.
• Act as a slave server for the sales.example.org zone, where serverB.example.org will be the master server.
• Define A records for serverA, serverB, smtp, ns1, and ns2.
• Define AAAA records (IPv6) for serverA-v6 and serverB-v6.
• Define smtp.example.org as the mail exchanger (MX) for the example.org domain.
• Define www.example.org as an alternative name (CNAME) for serverA. example.org, and define ftp.example.org as an alternative name for serverB.example.org.
• Finally, we will define contact information for serverA.example.org.

DNS Tools

host – host allows you to resolve hostnames into IP addresses from the command line. For example:

[root@serverA ~]# host internic.net

internic.net has address 198.41.0.6

Syntax and Options

host [-aCdlrTwv] [-c class] [-n] [-N ndots] [-t type] [-W time] [-R number] hostname [server]

• -a is equivalent to -v -t *
• -c specifies query class for non-IN data
• -C compares SOA records on authoritative nameservers
• -d is equivalent to -v
• -l lists all hosts in a domain, using AXFR
• -i uses the old IN6.INT form of IPv6 reverse lookup
• -N changes the number of dots allowed before root lookup is done
• -r disables recursive processing
• -R specifies number of retries for UDP packets
• -t specifies the query type
• -T enables TCP/IP mode
• -v enables verbose output
• -w specifies to wait forever for a reply
• -W specifies how long to wait for a reply

dig – The domain information gopher, dig , is a great tool for gathering information about DNS servers.

Syntax

dig [@global-server] [domain] [q-type] [q-class] {q-opt}

{global-d-opt} host [@local-server] {local-d-opt}

[ host [@local-server] {local-d-opt} […]]

Where: domain are in the Domain Name System. dig ’s usage summary is

dig @server domain   query-type

where @server is the name of the DNS server you want to query, domain is the domain name you are interested in querying, and query-type is the name of the record you are trying to get (A, MX, NS, SOA, HINFO, TXT, ANY, etc.).

nslookup – The nslookup utility is one of the tools that you will find exists across various operating system platforms. And so it is probably one of the tools that most people are familiar with. Its usage is quite simple, too. It can be used both interactively and noninteractively (i.e., directly from the command line).

Interactive mode is entered when no arguments are given to the command. Typing nslookup all by itself at the command line will drop you to the nslookup shell. To get out of the interactive mode, just type exit at the nslookup prompt.

whois – The whois command is used for determining ownership of a domain. Information about a domain’s owner isn’t a mandatory part of its records, nor is it customarily placed in the TXT or RP records. So you’ll need to gather this information using the whois technique, which reports the actual owner of the domain, their snail-mail address, e-mail address, and technical contact phone numbers.

nsupdate – An often-forgotten powerful DNS utility is the nsupdate utility. It is used to submit Dynamic DNS (DDNS) Update requests to a DNS server. It allows the resource records (RR) to be added or removed from a zone without manually editing the zone database files. This is especially useful because DDNS-type zones should not be edited or updated by hand, since the manual changes are bound to conflict with the dynamic updates that are automatically maintained in journal files, which may result in zone data being corrupt.

The rndc Tool – This is the “remote name daemon control” utility. It is handy for controlling the name server and also debugging problems with the name server.

The rndc program can be used to securely manage the name server. To do this, a separate configuration file is required for rndc, since all communication with the server is authenticated with digital signatures that rely on a shared secret, and this shared secret is typically stored in a configuration file, which is usually named /etc/rndc.conf. You will need to generate the secret that is shared between the utility and the name server by using tools such as rndc-confgen (we don’t discuss this feature here).

DNS Client Configuration

Under Linux, the resolver handles the client side of DNS. This is actually part of a library of C programming functions that get linked to a program when the program is started. Because all of this happens automatically and transparently, the user doesn’t have to know anything about it. It’s simply a little bit of magic that lets them start browsing the Internet. Configuring the DNS client involves only two files involved: /etc/resolv.conf and /etc/nsswitch.conf.

The /etc/resolv.conf file – The format of the /etc/resolv.conf file is as

searchdomainname

nameserverIP-address

where domainname is the default domain name to search, and IP-address is the IP address of your DNS server. For example, here’s a sample /etc/resolv.conf file:

search example.org

nameserver 127.0.0.1

Thus, when a name lookup query is needed for serverB.example.org, only the host part is needed, i.e., serverB. The example.org suffix will be automatically appended to the query.

The /etc/nsswitch.conf File – The /etc/nsswitch.conf file tells the system where it should look up certain kinds of configuration information ( services). When multiple locations are identified, the /etc/nsswitch.conf file also specifies the order in which the information can best be found.

The format of the /etc/nsswitch.conf file is simple. The service name comes first on a line (note that /etc/nsswitch.conf applies to more than just hostname lookups), followed by a colon. Next come the locations that contain the information. If multiple locations are identified, the entries are listed in the order in which the system needs to perform the search. Valid entries for locations are files, nis , dns , [NOTFOUND ], and NISPLUS. Comments begin with a pound symbol (#).

Back to Tutorial