DNS installation

DNS installation

http://www.garron.me/en/go2linux/how-setup-dns-server-master-slave-bind.html
http://tecadmin.net/step-by-step-installation-and-configuration-openldap-server-and-freeradius/#
http://www.zytrax.com/books/ldap/ch5/
http://computernetworkingnotes.com/network-administrations/dns-server.html

http://www.unixmen.com/dns-server-installation-step-by-step-using-centos-6-3/

/etc/named.conf

//
// /etc/named.conf
//

options {
    directory "/var/named";
    pid-file "/var/run/named/named.pid";
    auth-nxdomain yes;
    datasize default;
// Uncomment these to enable IPv6 connections support
// IPv4 will still work:
//  listen-on-v6 { any; };
// Add this for no IPv4:
//  listen-on { none; };

    // Default security settings.
    allow-recursion { 127.0.0.1; };
    allow-transfer { none; };
    allow-update { none; };
    version none;
    hostname none;
    server-id none;
};

zone "localhost" IN {
    type master;
    file "localhost.zone";
    allow-transfer { any; };
};

zone "0.0.127.in-addr.arpa" IN {
    type master;
    file "127.0.0.zone";
    allow-transfer { any; };
};

zone "." IN {
    type hint;
    file "root.hint";
};

//zone "example.org" IN {
//  type slave;
//  file "example.zone";
//  masters {
//      192.168.1.100;
//  };
//  allow-query { any; };
//  allow-transfer { any; };
//};

logging {
        channel xfer-log {
                file "/var/log/named.log";
                print-category yes;
                print-severity yes;
                print-time yes;
                severity info;
        };
        category xfer-in { xfer-log; };
        category xfer-out { xfer-log; };
        category notify { xfer-log; };
};




Create a Master Zone




To create a master zone, edit the file named.conf and add the following, in this example, I will create a zone for the domain linux10.com

zone "linux10.com" IN {
    type master;
    file "linux10.com.zone";
    allow-update { none; };
    allow-transfer { none; };
};

Then create the file linux10.com.zone in the folder stated in your options section of named.conf file.

The file should look at least like this:

$ORIGIN .
$TTL 86400      ; 1 day
linux10.com            IN SOA  primary.server.com. your.email.address. (
                            2010122801 ; serial
                            7200       ; refresh (2 hous)
                            7200       ; retry (2 hours)
                            2419200    ; expire (5 weeks 6 days 16 hours)
                            86400      ; minimum (1 day)
                            )
$TTL 14400      ; 4 hours
                    NS      scz.alketech.com.
                    NS      ns1.alketech.com.
                    A       10.1.1.1 ; If you want to assign a server to your domain
                   MX      10      mx1 ; Your email server if you have any
                   MX      20      mx2 ; Your secondary email server if you have one

$ORIGIN linux10.com.
www                     A       1.2.3.4 ; The IP of your web server if you want to have one.
mx1         A   1.2.3.5 ; The IP of your mx1 server
mx2         A   1.2.3.6 ; The IP of your mx2 server

Of course yours may have more or less lines and servers according to your needs.

Configure a DNS slave server with BIND

It is a good idea, to have slave server in case your master server is not reachable at any time.

Both master and slave need to defined as your DNS servers in your domain registrar, you may define more than just two server, and that is a good idea, it is also a good idea, to have your DNS server on different networks, I mean, if you have them on the same office/Data center, and that place loose Internet connectivity all your server will be out of reach, and you will loose traffic or emails or both.

For the visitors of your servers, any DNS server is the same and there is no difference between masters or slaves, so you should define one master and as many slaves as you want (anything between 2 to 4 slaves is OK).

Enable AXFR transfers

Your master DNS server should allow AXFR transfers to the slave servers for this to work, so the first step is to configure your master server to do so.

zone "linux10.com" IN {
    type master;
    file "linux10.com.zone";
    allow-update { none; };
    allow-transfer { ip.of.slave.server; ip.of.slave.server2; ip.of.slave.server3;};
};

Now create the slave zone in your slave servers.

On the slave server named.conf file you need to configure the slave zone, like this:

zone "linux10.com" {
    type slave;
    file "linux10.com.zon";
    masters { 1.2.3.4; };
    allow-transfer { none; };
};

Testing the configuration

dig @your.master.server your.domain.com ns

Example:

dig @scz.alketech.com linux10.com ns

You should get something like this:

; <<>> DiG 9.2.4 <<>> @scz.alketech.com linux10.com ns
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23659
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;linux10.com.                   IN      NS

;; ANSWER SECTION:
linux10.com.            14400   IN      NS      scz.alketech.com.
linux10.com.            14400   IN      NS      ns1.alketech.com.

;; ADDITIONAL SECTION:
ns1.alketech.com.       14400   IN      A       200.87.59.3
scz.alketech.com.       14400   IN      A       200.87.61.83

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec 29 15:35:20 2010
;; MSG SIZE  rcvd: 106

Final tunings

It is a good idea to disable recursion in your authoritative servers, either master or slave.

To do this, in your options section insert these lines

acl recurseallow { 1.2.3.4; 127.0.0.1; };
allow-recursion { recurseallow; };recursion yes;

Be sure to include this in the options section of the file /etc/named.conf for Arch Linux and Slackware and /etc/bind/named.conf.options for Debian.

Only for Slackware and Arch Linux

For Arch Linux and Slackware you need to enable the named daemon to start on each boot, to do this

On Arch Linux, edit the /etc/rc.conf file, and add it, to the daemons list

On Slackware, make the file /etc/rc.bind executable
permalink

If you enj








============================================================

The Domain Name System FAQs

The DNS is the addressing system for the Internet. Almost anything that interfaces with the Internet (e.g., computers, mobile devices, laptops, ATMs, and POS terminals) relies on DNS services to exchange information. DNS uses specialized servers to translate (or resolve) names such as www.verisigninc.com into numeric addresses that allow data and information to reach its destination. All Internet applications—ranging from websites, email, social networking, and online banking to Voice over Internet Protocol (VoIP), file sharing, and video on demand—depend on the accuracy and integrity of this translation. Without the DNS, the Internet cannot function. The DNS is integral to a nation's critical infrastructure, online business operations and financial transactions, and all Internet-based communications.



What is the DNS?

How does the DNS work?


The domain name space consists of a tree of domain names, subdivided into zones. The top-level or root zone is administered by the U.S. Department of Commerce (DoC) and jointly managed by Verisign and the Internet Assigned Numbers Authority (IANA) functions operator, who maintain the data in the root name servers.

A DNS zone consists of a collection of connected nodes served by an authoritative name server. Authoritative name servers for different zones are responsible for publishing the mappings of domain names to IP addresses. Each node or leaf in the tree has zero or more resource records that hold information associated with the domain name. Every domain name ends with a top-level domain (TLD) such as .com or .tv.

For the Internet to function and to prevent duplication of domain names, there must be one authoritative place to register a domain name. Each TLD has an authoritative registry, which manages a centralized database. The registry propagates the information about domain names and IP addresses in TLD zone files. TLD zone files map active second-level domain names (the portion of the domain name that appears immediately to the left of ".") to the unique IP addresses of the name servers.


Why is DNS vulnerable?


The process of translating a domain name into an IP address is called DNS resolution. When someone types a domain name, such as www.verisigninc.com, into a web browser, the browser contacts a name server to obtain the corresponding IP address. There are two types of name servers: authoritative name servers, which store complete information about a zone, and recursive name servers, which answer DNS queries for Internet users and store DNS response results for a period of time. When a recursive name server receives a response, it caches (stores) it to speed up subsequent queries. Caching helps reduce the number of information requests required, but it is susceptible to man-in-the-middle attacks.

As a result of these attacks, cyber criminals can:

    Hijack emails
    Tap Voice over IP (VoIP)
    Impersonate websites
    Steal passwords and login information
    Extract credit card data and other confidential information

Learn more about threats to the DNS system.


What is cache poisoning?
Cache poisoning occurs when fraudulent DNS data is inserted into the cache of a recursive name server. Recursive name servers temporarily store, or cache, information learned during the name resolution process, but without DNSSEC they have no way to ensure the validity and accuracy of this information. When malicious information is cached on the recursive name server, the server is considered "poisoned." Cache poisoning allows an attacker to redirect traffic to fraudulent sites.


What are man-in-the-middle (MITM) attacks?
A man-in-the-middle (MITM) attack surreptitiously intercepts and modifies communications between two systems. The attacker can potentially modify the communication to redirect traffic to an illegitimate address or website. End users do not detect the "man in the middle" and assume that they are communicating directly with their intended destination.

DNS by example

Start of Zone Authority
The SOA resource records provide the information that’s needed to resolve domain names to IP
addresses. These files are typically stored in the /var/named directory, but you can name them
anything you want. For this example, I’ll name my SOA file /var/named/xyz.com.

The SOA resource records require a number of fields.
You can include comments in the resource file by typing a semicolon (;) before the comment.

The file entry is as follows,
@ IN SOA sama.expanor.local root.expanor.local (
 2014061601 ; serial number
 3600 ; refresh (1hrs)
 3600 ; retry (1hr)
 151200 ; expire (1 week)
 86400 ) ; default TTL
here, the SOA resource file gives you some detail about the SOA record.
1. The @ symbol represent the dmain name of for the zone.
2. The IN statement stands for Internet Name, and SOA tells that we are defining the SOA for
our domain (ie expanor.local).
3. The first domain name after SOA defines the primary name server for this domain
(sama.expanor.local).
4. The second field is the administractive email address (root@sama.expanor.local.
(Note: email address uses . (period) rather than @ character in SOA record.
5. After the email address, you start with an opening parenthesis to start the numeric
statements. The next lines indicate parameters for the server.
6. The first number is the serial number, eg, date.01 ( 2014061601; dateVERSION).
Note: Every time you change the resource record, you need to increase the serial number by one
before you restart the service 'named'. When secondary checks for the new information, it first
checks the serial number to make sure it gets the latest information. If serial number is
larger than on the slave, then slave performs a zone transfer. If you never increase this
number, your changes will never take effect.
7. The second number is the refresh rate in second. What this mean is that the value tells the
DNS servers how ofter they should query the primary server to if if there is change in records
that need to be updated.
8. The third number is to check for updates (retires) in seconds if it (slave server) can't
contact it (master) at first attempt.
9. The fourth number is for the slave server which cache the entry. If some reason slave
(secondary) server can't communicate with primary (master) server for a update, they will
discard the cache value after the specified number of seconds. Normally the value is defined
for a week.
10. The last number is for how long the caching servers should wait before allowing an entry to
expire if they can't contact the primary (master) DNS server. Normal value is 5-7 days.
11. Now, you clise the statement with parenthesis.

NS servers
Now, the next entries should be the authoritative NS (Name Server) servers for your domain.
Using the previous example, we would type something like this:

NS sama.expanor.local.
NS sam.expanor.local.
There are two authoritative name servers for the expanor.local domain: sama.expanor.local (the
computer that we’re currently setting up) and sam.expanor.local (a secondary or backup or slave
DNS server). Since both are fully qualified hostnames, they need to have periods after their
names.
Note: If you write the above lines as sama.expanor.local and not as sama.expanor.local, the
server would translate the addresses as sama.expanor.local.expanor.local
MX records
The next etry is for MX (Mail exchanger) record. This entry tells the outside world that the
defined machine will receive mail from external networks. Depending on your environment, you
can have one or two mail (primary/secondary or backup) server. for eg,
MX 10 sama.expanor.local
MX 20 sam.expanor.local

The lines above tells the external networks to try to deliver the mails to sama.expanor.local
first and if its not available, then try to deliver to sam.expanor.local. The number on second
coloum is the priority number. Lower the number higher the priority. So sama will recieve all
the mails unless it is not reachable on the network.

A records
The next entry is A (Address record) records. The address records (A) translates hostname to
ipaddress. You should have A record for all the machines in a network if you want to have a
recognized hostnames. The entry can be as follows.
sama A 192.168.10.110
sam A 192.168.10.8
jay A 192.168.10.160
These lines tell the DNS server that sama.expanor.local is mapped with ip address
192.168.10.110 and jay is mapped with 192.168.10.160
Note: Since there is no period after the hostname, the DNS server assumes that the domain name
is retain from the current SOA record (expanor.local SOA).
CNAME records (Canonical Name)
Canonical Name (CNAME) records also known as hostname aliases is any other name (common names)
that you want to define for the hostname. That is using CNAME, you can use friendly name to
represent the host. For eg, if you have to define a mail serverm, you can do as follows,
mail.expanor.local
sama.expanor.local
which represent the same server and can be reached through either name.
Note: For CNAME to work, you must define an address (A) or Mail Exchange (MX) record. for eg,
sama IN A 192.168.10.110
mail IN CNAME sama
www IN CNAME sama
ftp IN CNAME sama
mail2 IN CNAME sam

mail.expanor.local, www.expanor.local and ftp.expanor.local map to sama.expanor.local. You also
have to define the alias for mail2.expanor.local which points to sam.expanor.local.
Now, the final forward lookup resolution for the domain expanor.local looks like follows,


$ cat /var/named/expanor.frwd
@ IN SOA sama.expanor.local root.expanor.local (
 2014061601 ; serial number
 3600 ; refresh (1hrs)
 3600 ; retry (1hr)
 151200 ; expire (1 week)
 86400 ) ; default TTL
; specify the name servers for the domain.
NS sama.expanor.local.
NS sam.expanor.local.
; define mail servers
MX 10 sama.expanor.local
MX 20 sam.expanor.local
; define the ipaddress for the server
sama A 192.168.10.110
sam A 192.168.10.8
jay A 192.168.10.160
; define alias
mail IN CNAME sama
www IN CNAME sama
ftp IN CNAME sama
mail2 IN CNAME sam

Reverse address resolution database
Now, we have primary SOA and we have to define the reverse lookup information to match the
record.

$ cat /var/named/expanor.frwd
@ IN SOA sama.expanor.local root.expanor.local (
 2014061601 ; serial number
 3600 ; refresh (1hrs)
 3600 ; retry (1hr)
 151200 ; expire (1 week)
 86400 ) ; default TTL
; define name servers
NS sama.expanor.local.
NS sam.expanor.local.

110 IN PTR sama
8 IN PTR sam
160 IN PTR jay
so the SOA and the NS records are exactly the same. The new record type here is the pointer
(PTR) record which is also called reverse resolution record and maps the ipaddress to hostname.
 We define the last octet of the ip address for the defined hostnames which the 'named' service
 points to the ip address 192.168.10.110 to host sama. which resolves to sama.expanor.local and
so on.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[root@sama named]# more /etc/named.conf
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//

options {
        listen-on port 53 { 127.0.0.1; 192.168.10.110; };       #Specify your DNS server
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { localhost; 192.168.10.0/24; };                # Range of IP
#       allow-transfer  { localhost; 102.168.10.8;};            # Secondary DNS server
        recursion yes;

        dnssec-enable yes;
        dnssec-validation yes;
        dnssec-lookaside auto;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
        type hint;
        file "named.ca";
};

//zone "0.0.127.in-addr.arpa" in {
//      type master;
//      file "home.local";
//};

// Define your zone here

zone    "expanor.local" IN {
        type master;
        file "expanor.forward.zone";
        allow-update { none; };
        };

// Specify your reverse zone info
zone    "10.168.192.in-addr.arpa" IN {
        type master;
        file "expanor.reverse.zone";
        allow-update { none; };
        };

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

**************************************************************** 

[root@sama named]# more expanor.forward.zone
$TTL 86400
@       IN      SOA     sama.expanor.local. root.expanor.local.(
        201504191; Serial #
        3600    ; Refress interval
        1800    ; Retry time
        604800  ; Expire time
        86400   ; Max time to live TTL
)
@       IN NS   sama.expanor.local.  ; Primary DNS server
@       IN NS   sam.expanor.local.  ; secondary DNS server
@       IN MX 10 mail.expanor.local. ; Mail server MX record
;
sama    IN A    192.168.10.110
sam     IN A    192.168.10.8
suvi    IN A    192.168.10.115
chandra IN A    192.168.10.150
surya   IN A    192.168.10.160
jay     IN A    192.168.10.170
devi    IN A    192.168.10.180
pramila IN A    192.168.10.190
myu     IN A    192.168.10.20
ram     IN CNAME        sama
mail    IN CNAME        sama
vmware  IN A    192.168.10.99
beena   IN A    192.168.10.111
mohan   IN A    192.168.10.220
bikash  IN A    192.168.10.221
kuldeep IN A    192.168.10.222
fairfax IN A    192.168.10.250

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

[root@sama named]# more expanor.reverse.zone

$TTL    864000;

@       IN SOA  sama.expanor.local. root.expanor.local. (

        201504191       ; Serial #

        3600            ; Refresh time

        1800            ; Retry time

        604800          ; Expire

        86400)          ; Minimum TTL

;$TTL 1D

;

;@       IN      SOA     sama.expanor.local root.expanor.local. (

;201406110       ; serial

;2H              ; refresh slaves

;5M              ; retry

;1W              ; expire

;1M              ; Negative TTL

;)

           NS   sama.expanor.local.

           NS   sam.expanor.local.

;

110     IN PTR  sama.expanor.local.

8       IN PTR  sam.expanor.local.

150     IN PTR  chandra.expanor.local.

160     IN PTR  surya.expanor.local.

180     IN PTR  devi.expanor.local.

170     IN PTR  jay.expanor.local.

190     IN PTR  pramila.expanor.local.

20      IN PTR  myu.expanor.local.

99      IN PTR  vmware.expanor.local.

250     IN PTR  fairfax.expanor.local.

[root@sama named]#

[root@sama named]# cat /etc/resolv.conf
# Generated by NetworkManager
search expanor.local
nameserver 192.168.10.110

[root@sama named]# more /etc/nsswitch.conf

hosts:      files dns

updated info,

[root@localhost opt]# dig sama.expanor.local

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.2 <<>> sama.expanor.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6583
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;sama.expanor.local. IN A

;; ANSWER SECTION:
sama.expanor.local. 86400 IN A 192.168.10.110

;; AUTHORITY SECTION:
expanor.local. 86400 IN NS sam.expanor.local.
expanor.local. 86400 IN NS sama.expanor.local.

;; ADDITIONAL SECTION:
sam.expanor.local. 86400 IN A 192.168.10.8

;; Query time: 2 msec
;; SERVER: 192.168.10.110#53(192.168.10.110)
;; WHEN: Mon Apr 20 07:47:16 2015
;; MSG SIZE  rcvd: 100


Let's examine the some dig output values:

Look at the section between Got answer and Question Section,  you will see the header information.
The line beginning with ->> HEADER <<- is the first part of the header of the reply message that dig received from the remote name server. The opcode in the header is always QUERY, just as it is with nslookup. The status is NOERROR; "Showing the Query and Response Messages". The ID is the message ID, a 16-bit number used to match responses to queries.

Just belo the line, you see the 'flags'. glags tell us more about the response. qr indicates that the message was a response, not a query. dig decodes responses, not queries, so qr will always be present. Not so with aa or rd, though. aa indicates that the response was authoritative, and rd indicates that the recursion desired bit was set in the query (since the responding name server just copies the bit from the query to the response). Most of the time rd is set in the query, you'll also see ra set in the response, indicating that recursion was available from the remote name server.

The next field tells you that dig asked one question and received one answer in ANSWER section, 2 on AUTHORITY section and 1 additional information.

At the end, dig gives the summary information about the query and response. The first line shows you how long it took the remote name server to return the response after dig sent the query. The second line shows you from which host you sent the query and to which name server you sent it. The third line is a timestamp showing when the response was received. And the fourth line shows you the size of the query and the response, in bytes.


http://www.techrepublic.com/article/setting-up-a-dns-server-under-linux-part-1-the-
configuration/