Jump to content

FOSS Network Infrastructure and Security/Major Networking Functions with FOSS

From IdeaWazaWiki
Revision as of 10:55, 29 May 2007 by wikademia>Stine loft (→Resolver configuration)

Domain Name System

DNS is the glue that keeps the technical side of the Internet connected to the users of the network. Simply stated, the DNS provides names to IP address translation and vice versa. The Internet is based on the IP protocol, which means that computers on the Internet know the path to each other only through the IP addresses. However, remembering the numerical IP address of each computer on the Internet is not possible for most people. Here is where DNS comes in handy.

The main purpose of DNS is to map names to objects on the Internet. The object may be an IP address or the identification of mail servers, name servers, and even personal telephone numbers. Names, after all, are easier to remember than numbers.

The earlier version of DNS was a file named hosts.txt, which was manually maintained by the Stanford Research Institute-Network Information Center (SRI-NIC) in the early days of the ARPANET[1] in the 1970s. This hosts.txt file was updated on a single computer and pulled by computers all over the world. While this method worked for some time, name collision became imminent when more hosts were added to the network. The flat single file mapping was simply not scalable. Thus DNS was created. It is defined in RFC 1034 and 1035.

DNS consists of three components:

  • DNS name space – the domain names;
  • DNS server – the server that hosts the name space; and
  • Resolver – the client which uses the server.

The three components work in tandem to create a viable solution to name resolution. DNS is designed in such a way that all the data are maintained locally but retrievable globally. The data is distributed among different name servers and no single computer has all of the data. The data is internally always consistent, thereby providing a stable system. Moreover, DNS is designed in such a way that any device can send DNS queries to a server.

DNS Name Space

DNS name space is a concept. Names are references to addresses, objects and physical presences that constitute a human, understandable reference identifying an endpoint. DNS name space is the name space defined for DNS. On the Internet, domain names provide a hierarchy for DNS name space, and thus, an order to how Internet addresses are identified.

Let’s take a comparative example. If someone were to send me a letter, it would be addressed to

Gaurab Raj Upadhaya

205/8 Sahayogi Marg, Kathmandu, Nepal

In this example, the address provides a way in which the letter can be sent to me from anywhere in the world. Similarly, if someone were to send me an e-mail, they could use either of the following e-mail addresses:

gaurab@wlink.com.np

gaurab@lahai.com

In both cases, while the e-mail ends up in the same mailbox, it travels differently to that address. What needs to be understood is the domain hierarchy that makes the e-mail work. It is part of the DNS name space. Domain names are the implementation of DNS name space. The domain name system uses an inverted tree-shaped structure. The topmost level of the DNS tree is called the ‘root’.[2] The ‘root’ is referenced with a ‘ . ’ (dot). Immediately below the ‘root’ are the Country Code Top Level Domain (ccTLD) and the Global Top Level Domain (gTLD). These two top levels are predefined and fixed on a global scale. The ccTLDs are assigned as per the ISO 3166 standard. The gTLDs are decided by the Internet Corporation for Assigned Name and Numbers (ICANN). Examples of ccTLDs are .np, .in, .my, .uk, .se, etc. ccTLDs are always two letter codes. Examples of gTLDs are .com, .org, .net, .gov, .edu, .mil, .info, .name, and .aero.

Domains and Sub Domains

Below the TLDs are the user level spaces. These are commonly referred to as the domain names. For example, anything under .net is in the net domain, and anything under .uk is under the UK domain. And by extension, a sub domain under lahai.com, such as evo.lahai.com, is under the lahai.com domain.

Every domain created under an upper level domain is referred to as a sub domain. Thus, in the example above, evo.lahai.com is a sub domain under lahai.com.

Zones and Delegation

In computer terms, each DNS name space is reflected by its zone file. It is also referred to as the ‘administrative name space’. Each domain or sub domain on a name server has its own zone file, which is the main file that provides the mapping.

What makes DNS so scalable is its ability to define a delegation for sub domains to other servers and other zone files. Thus, the root zone file delegates ccTLD and gTLD functions to their respective servers, and each ccTLD or gTLD server further delegates specific domain information to their registered owners. Thus, the actual names to object mapping will be provided only by the authoritative zone for that domain. This procedure can be compared to a parent delegating authority to his/her child.

Name Servers

Name servers host the DNS zone files. They answer queries directed to them. Name servers are of two types.

1. Authoritative name servers

  • master
  • slave

2. Non-authoritative name servers

  • caching name servers
  • caching forwarders

Most implementations are a combination of two or more types.

Authoritative Name Servers

Authoritative name servers host the main zone files for the designated domain. The authority of the name server is based on delegation from the upper level domain. Thus for any server to be authoritative for evo.lahai.com domain, it has to be delegated in the lahai.com zone file.

The master file is where the main file is hosted. The slave mirrors the file from the master. There can be multiple slave servers to one master server. A single master server can support more than 20 million names, but it might not be a good idea to actually do this. Different DNS server software are capable of handling large numbers of DNS queries. A commonly cited example is 300,000 queries per second. Changes in the master copy of the database are replicated to the slaves immediately or according to timing set by the administrator.

Recursive Name Server

A recursive name server is not authoritative for all domains for which it is serving data. It acts on behalf of other clients, and caches the result in its memory. If the same query is sent within a predefined time period, then instead of searching the entire DNS structure, it serves the data from the cache. In case of caching forwarders, the server uses another DNS server to get the result. When the data are forwarded to the client, they are marked as non-authoritative.

Mixed Implementation

In smaller organizations, a single name server can be used for multiple purposes. A server can be authoritative for a select few domains but it may also serve as a non-authoritative caching server for other domains. With recent cases of DNS cache poisoning, it is strongly recommended that the same server not be used for both authoritative and caching functions.

Resolver

The resolver is the client that asks the server for the DNS data. The resolver is normally implemented at the operating system level in the form of a library, so that multiple applications can use it.

DNS Security

A big strength of the Internet is in the user’s ability to use names to reach the right servers and systems. A mis-configured DNS or a malformed DNS query can deter users; hence, the need for a secure DNS system. It is very important to follow these simple points:

  • Allow only authorized systems to do zone transfers from the master server.
  • Have a minimum of two DNS servers, and remember not to put them in the same location.
  • Make sure that your forward and reverse DNS information is consistent.
  • Follow current best practices for DNS implementation.

Using BIND for DNS

BIND is an implementation of the DNS protocols. It provides an openly re-distributable reference implementation of the major components of the domain name system, including:

  • A DNS server (named);
  • A DNS resolver library; and
  • Tools for verifying the proper operation of the DNS server.

The BIND DNS server is used on the vast majority of name serving machines on the Internet, as it provides a robust and stable architecture on top of which an organization’s naming architecture can be built. The resolver library included in the BIND distribution provides the standard interface for translation between domain names and Internet addresses and is intended for linking with applications requiring name service.

Getting and Installing BIND

BIND is normally installed by default by most GNU/Linux distributions. Otherwise, you can always get a copy from the BIND home page at http://www.isc.org/products/BIND/. The installation process of BIND in different distributions of GNU/Linux may differ. It is best to follow the distribution guide for installation.

Configuration of BIND

The BIND configuration has to be undertaken in three stages.

First, the client side or the resolver library needs to be configured, followed by the server itself and finally, the tools.

Resolver configuration

The resolver is the client side of the DNS system. Even if you do not run a DNS sever on the computer, you will need to have the resolver installed. Naturally, in order to configure BIND, you first need to configure the resolver library. This is done by configuration of the following files:

/etc/host.conf

This file specifies how the host name resolution is performed. This has been made obsolete, but older installations may still use it.

/etc/nsswitch.conf

This file has replaced host.conf. It specifies the order in which name resolution takes place. It tells the computer the order in which it should try to convert names into IP addresses.

# /etc/nsswitch.conf

Any line starting with a # sign is a comment.

'#' In this example, hosts are resolved through DNS, and then from files.

hosts: dns files

"#" only files are used for network name resolution

networks: files

The default file created during installation is usually sufficient.

/etc/resolv.conf

resolv.conf is the basic DNS configuration file, which specifies the DNS server and the domain name. The three key words here are ‘domain’, ‘search’, and ‘nameserver’.

  1. /etc/resolv.conf
  2. Our domain

domain gaurab.org.np # Default search domains in order of priority search gaurab.org.np lahai.com.np # # We use the local server as the first name server. nameserver 127.0.0.1 # we have second name server at up stream provider. nameserver 206.220.231.1

This file is also created during the installation, and if your network configurations have not changed, you can leave it unchanged.

Server configuration

‘named’ is the best known FOSS DNS daemon. A daemon is a software program that runs continuously on the server as a service. The DNS server is thus commonly referred to as the ‘name daemon’ or just ‘named’. The file name of the DNS server is also ‘named’.

For BIND versions 4.x.x, named used the configuration file/etc/named.boot. But in the later versions of BIND (8.x.x), the configuration file is /etc/named.conf.

For our purposes, we use /etc/named.conf. In the following example, a master DNS for the domains lahai.com and gaurab.org.np is specified. A slave DNS for domain wlink.com.np is also shown.

// // /etc/named.conf file for ns.lahai.com // in this file ‘//’ is the comment.

// you specify the default data directory for DNS. Now all DNS // related files should go into /var/named or any other // directory as specified.

options { directory “/var/named”; };

// First you need to add the DNS root zone file name. It’s there // by default.

zone “.” { type hint; file “named.ca”; };

// Now we are specifying a master domain called lahai.com // whose information is stored in the file ‘named.lahai.com’

zone “lahai.com” { type master; file «named.lahai.com»; };

// the whole thing can also be done in a single line.

zone “gaurab.org.np” { type master; file “named.gaurab.org.np”;};

// Now this server is also a slave for another domain “wlink.com.np’

zone “wlink.com.np” { type slave; masters { 202.79.32.33; }; file “slave/named.wlink.com.np”; };

zone “0.0.127.in-addr.arpa” { type master; file “named.local”; }

This file sets the stage for adding the real data about host name and IP addresses. The /etc/named.conf file can take a lot of additional configuration directives, but these will not be discussed here.

After relevant entries have been made in the named.conf file, it is necessary to create the host name records for the corresponding domains. All of the files should be placed in the directory specified by the directory directive in the named.conf file.

The named.local file provides reverse zone lookup for the loopback interface or the 127.0.0.0 network used by the loopback addresses. The default file should be left unchanged. The named.ca provides the root server information to the DNS server. The default should never be edited. Now let’s look at a sample DNS file for the domain lahai.com (named.lahai.com)

; file /var/named/named.lahai.com @ IN SOA ns.lahai.com. gaurab.lahai.com. ( 2004050801 ; serial number 86400 ; refresh: once per day (1D) 3600 ; retry: one hour (1H) 3600000 ; expire: 42 days (6W) 604800 ; minimum: 1 week (1W) )

we are specifying three Name servers.

IN NS ns.lahai.com. IN NS a.ns.hopcount.ca. IN NS ns1.lahai.com.

local mail is distributed on another server

IN MX 10 mail.lahai.com. IN MX 20 ns.lahai.com.

loopback address

localhost. IN A 127.0.0.1

The glue records so that the NS records can resolve.

ns IN A 204.61.208.110 ns1 IN A 202.79.55.14

main DNS entry

www IN A 207.189.222.2 mail IN A 202.51.76.8

Aliases for the www machine.

tftp IN CNAME www

The above file is the main file for the domain ‘lahai.com’. If you want to add additional names for the domain ‘lahai.com’, like pop3.lahai.com and smtp.lahai.com, then you should add them in the above file.

The order in which the name servers are listed in this file makes them master and slave. The first NS is always the master server and the other two are slave servers. Each time the master server is updated, it can automatically send a notification to the other NS servers listed in the file. This parameter can be configured in the named.conf file.

A note about Reverse DNS

The majority of DNS-related problems are usually due to mis-configured reverse DNS. Reverse DNS is the mapping of numbers into names, or the opposite of the forward name resolution. Many applications use this facility to verify that the network source IP address is valid. A common example is SPAM or unsolicited commercial e-mail (junk e-mail) prevention software, which may refuse to accept mails from any domain that does not have a reverse DNS configured.

The reverse DNS works through delegation of the particular group of IP addresses from one of the Regional Internet Registries (RIRs), which is Asia Pacific Network Information Centre (APNIC) (http://www.apnic.net) in the Asia-Pacific region. Since Internet Service Providers (ISPs) are normally APNIC members, they are responsible for configuring the appropriate reverse DNS for the IP addresses being used by them and their clients.

Since each computer has its own loopback interface and the IP address associated with it, BIND comes with the default installation of the named.local file, which is the reverse DNS for 127.0.0.0 network. This file looks like the following:

; /var/named/named.local $TTL 86400 @ IN SOA localhost. root.localhost. ( 1997022700 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS localhost. 1 IN PTR localhost.

Administrating BIND DNS

BIND includes a utility called rndc that allows you to administer the named daemon, locally or remotely,with command line statements. The rndc program uses the ‘/etc/rndc.conf’ file for its configuration options, which can be overridden with command line options.

Before you can use the rndc, you need to add the following to your named.conf file:

/etc/named.conf controls { inet 127.0.0.1 allow { localhost; } keys { <key-name>; }; };

key “<key-name>” { algorithm hmac-md5; secret “<key-value>”; };

In this case, the <key-value> is an HMAC-MD57[3] key. You can generate your own HMAC-MD5 keys with the following command:

dnssec-keygen -a hmac-md5 -b <bit-length> -n HOST <key-file-name>

A key with at least a 256-bit length is a good idea. The actual key that should be placed in the <keyvalue> area can be found in the <key-file-name>.

Configuration file /etc/rndc.conf

options { default-server localhost; default-key “<key-name>”; }; server localhost { key “<key-name>”; }; key “<key-name>” { algorithm hmac-md5; secret “<key-value>”; };

The <key-name> and <key-value> should be exactly the same as their settings in /etc/named.conf.

To test all of the settings, try the rndc reload command. You should see a response similar to this:

rndc: reload command successful

You can also use the rndc reload to reload any changes made to your DNS files.

DNS Tools

There are two common tools to test DNS: nslookup and dig. Nslookup is the older of the two, and is less preferred. You can use the dig utility to test the DNS service. Use the command ‘man dig’ on most Unix and Unix-like systems to access the relevant manual pages.



Footnotes

  1. ↑ Advanced Research Program Agency Network is considered the precursor to the current Internet.
  2. ↑ Not to be confused with the ‘root’ user on GNU/Linux and Unix systems.
  3. ↑ A popular way to encrypt. It uses a one way hash algorithm for encryption.
Retrieved from "https://ideawaza.com/index.php?title=FOSS_Network_Infrastructure_and_Security/Major_Networking_Functions_with_FOSS&oldid=51874"