Site icon Tutorial

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

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

DNS Terms

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:

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

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:

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

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

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]

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

Apply for Linux Administration Certification Now!!

http://www.vskills.in/certification/Certified-Linux-Administrator

Exit mobile version