Leksion 05 - DNS


Domain Name Service (DNS)

Domain Name Service (DNS) eshte nje sherbim i Internetit qe perkthen emrat e pajisjeve ne adresa IP dhe anasjelltas. Ubuntu perdor BIND (Berkley Internet Naming Daemon), serveri DNS me popullor ne ambjente Linux.




Instalimi
Instalojme fillimisht paketen e BIND:


yum install bind*


Rolet e nje serveri DNS

Ka disa menyra per te konfirgurar nje server DNS ne Linux.
Disa nga konfigurimet me te zakonshme jane :

caching nameserver

Nje caching nameserver BIND do te kerkoje per pergjigje dhe me pas do te ruaje ato ne historikun e tij per tiu ripergjigjur te njejtave pyetje. Nuk ka nje zone te veten.

primary master

Nje server DNS primary master ka zonen e tij DNS per te cilen pergjigjet ne menyre autoritare.


secondary master.

Nje server DNS sekondar lexon skedarin me te dhenat e zones nga serveri primar dhe i pergjigjet kerkesave te klienteve me te dhenat qe ka kopjuar nga primari.


Skedaret e konfigurimit

Skedaret e konfigurimit te DNS ruhen ne dosjen /etc/named.
Skedari i pare i konfigurimit eshte /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.221.80; };
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 { 192.168.221.0/24; };
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";
};


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


Skedari /etc/named.rfc1912.zones

Ruan informacion mbi zonat baze qe ka serveri DNS , si per shembull zonen localhost.


Me poshte eshte nje shembull i skedarit


// named.rfc1912.zones:
//
// Provided by Red Hat caching-nameserver package
//
// ISC BIND named zone configuration for zones recommended by
// RFC 1912 section 4.1 : localhost TLDs and address zones
// and http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt
// (c)2007 R W Franks
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//


zone "localhost.localdomain" IN {
type master;
file "named.localhost";
allow-update { none; };
};


zone "localhost" IN {
type master;
file "named.localhost";
allow-update { none; };
};


zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "named.loopback";
allow-update { none; };
};


zone "1.0.0.127.in-addr.arpa" IN {
type master;
file "named.loopback";
allow-update { none; };
};


zone "0.in-addr.arpa" IN {
type master;
file "named.empty";
allow-update { none; };
};



Skedari named.ca

Me poshte eshte permbajtja e nje skedari named.ca shembull

; <<>> DiG 9.5.0b2 <<>> +bufsize=1200 +norec NS . @a.root-servers.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34420
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;. IN NS


;; ANSWER SECTION:
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.


;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201
C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12
D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90
E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10
F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241
F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f
G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4
H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53
H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235
I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17
J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30
J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30
K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129
K.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:7fd::1
L.ROOT-SERVERS.NET. 3600000 IN A 199.7.83.42
M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33
M.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:dc3::35


;; Query time: 147 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Feb 18 13:29:18 2008
;; MSG SIZE rcvd: 615



Skedari /etc/named.rfc1912.zones

Ruan informacion mbi zonat per te cilat eshte pergjigjes ky server DNS , si per shembull zonen ict.local


Kofigurimi i serverit DNS

Konfigurimi si Caching Nameserver

Konfigurimi baze eshte caching server. i vetmi konfigurim qe kerkohet eshte qe te vendosen IP e serverave te ISP si forwareds. Kjo behet duke modifikuar skedarin /etc/named.conf:


forwarders
{
1.2.3.4;
5.6.7.8;
};





Konfigurimi si Primary Master

Ne shembullin me poshte BIND9 do te konfigurohet si nje Primary Master per domain example.com.
Forward Zone File


Per te shtuan nje zone DNS ne BIND9, duke e kthyer ate ne nje Primary Master server, hapi i pare eshte editimi i /etc/named.rfc1912.zones:


zone "example.com"
{
type master;
file "db.example.com";
};


Me tej krijojme skedarin e databazes me rekordet e zones tone nen emrin db.example.com :


; BIND data file for example.com
;
$TTL    604800
@       IN      SOA     example.com. root.example.com. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
        IN      A       192.168.1.10
;
@       IN      NS      ns.example.com.
@       IN      A       192.168.1.10
@       IN      AAAA    ::1
ns      IN      A       192.168.1.10





Duhet modifikuar skedari /db.example.com duke vendosur emrin e plote FQDN te domain tone, pa e hequr piken ne fund "." .
Vendoset adresa IP e serverit DNS dhe root.example.com me adresen e email te administratorit te domain , por me "." ne vend te simbolit te zakonshem te email ".

Sqarime ne lidhje me permbajtjen e skedarit te zones:

$TTL
Default TTL - Time To Live. $TTL percakton kohe baze te vlefshmerise te te gjithe rekordeve ne skedar, ne rast se ajo nuk percakothet ne menyre specifike per nje rekord. Njesia matese eshte ne sekonda.
Nje vlere a zakonshme mund te jete 86400 sekonda ose 24 ore. Kjo vlere percakton se per sa kohe do te reflektohet ndryshimi i nje rekordi ne serverat DNS neper interenet.
Dynamic DNS (DDNS) zakonisht perdor nje TTL te barabarte me 5 minutes, ose 300 sekonda.


SOA
SOA (Start Of Authority) tregon cili eshte serveri qe eshte pergjegjes per kete zone , qe do te thote se ky server eshte serveri autoritar per kete zone. Mund te kete vetem nje rekord SOA ne cdo skedar te dhenash te domain (db.DOMAIN).


Te shpjegojme cfare permban SOA:

emri i domain psh @ ose ict.local.
IN = Internet
SOA = Start of Authority
emri i serverit SOA (per shembull localhost ose myserver.ict.local.)
email i administratorit te domain per shembull admin.ict.local. ose root.localhost. qe do te interpretohen si admin@ict.local ose root@localhost
Me pas midis kllapave:
(

numri serial, qe tregon versionin e skedarit te te dhenave. Ky numer perdoret nga serveri sekondar i DNS per te kuptuar nese ka ndryshuar skedari i te dhenave qe nga hera e fundit qe ai eshte sinkronizuar?
refresh , i tregon serverit sekondar pas sa kohesh duhet te pyese serish serverin primar nese ka ndryshuar skedari i te dhenave
retry, i tregon serverit sekondar pas sa kohesh duhet te riprovoje nese nuk mundi qe te kontaktoje me serverin primar
expiry, i tregon serverit sekondar se pas sa kohesh qe nuk ka komunikuar me serverin primar te dhenat e tij jane te pavlefshme
Negative Cache TTL , i tregon klienteve DNS te cilet kane marre nje pergjigje negative per nje rekord nga serveri i DNS se sa kohe do ta mbajne mend kete pergjigje perpara se te pyesin serish serverin SoA)


Me poshte vazhdojme me rekordet e tjesa DNS


NS= Name Server
A = A host ( emer -> adrese)
PTR = POINTER (adrese->emer)
CNAME= Canonical Name ose Sinonim


Reverse Zone File


Eshte e mundur madje e rekomandueshme qe te shtohet gijthashtu nje zone reverse qe perkthen nga IP ne emra:


Editoni /etc/named.rfc1912.zones shtuar nje rekord per zonen reverse:



zone "1.168.192.in-addr.arpa"
{
type master;
file "db.192";
};



Tani krijoni skedarin db.192 :

;
; BIND reverse data file for local 192.168.1.XXX net
;
$TTL    604800
@       IN      SOA     ns.example.com. root.example.com. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      ns.
10      IN      PTR     ns.example.com.



Edhe ne zonen reverse duhet te kujdesemi per inkrementimin e Numrit Serial sa here qe modifikojme skedarin e zones. Per cdo rekord A te krijuar ne zonen forward ne db.example.com, eshte e nevojshme te krijojme nje rekord PTR ne skedarin e zones reverse db.192.

Pas modifikimit te zones reverse duhet gjithashtu restartuar sherbimi per te aplikuar ndryshimet :


service named restart



Konfigurimi si Secondary Master

Pasi kemi konfiguruar nje Primary Master mund te shtojme nje Secondary Master per te garantuar disponibilitin e sherbimit ne rast te mos disponibilitetit te Primary .

Se pari, ne serverin Primary Master , duhet lejuar transferimi i zones .

Kjo behet duke shtuar opsionin
allow-transfer tek zonat Forward dhe Reverse ne /etc/named.rfc1912.zones:



zone "example.com"
{
type master;
file "db.example.com";
allow-transfer { 192.168.1.11; };
};





zone "1.168.192.in-addr.arpa"
{
type master;
file "db.192";
allow-transfer { 192.168.1.11; };
};


Vendosni IP e serverit Tuaj sekondar ne vend te IP 192.168.1.11 .

Restartoni named tek Primary Master:

service named restart



Se dyti , tek Secondary Master, instaloni paketen named ne te njejten menyre si tek Primary.

Me pas editoni /etc/named.rfc1912.zones dhe shtoni deklarimet e meposhtme per zonat Forward dhe Reverse :

zone "example.com"
{
type slave;
file "db.example.com";
masters { 192.168.1.10; };
};



zone "1.168.192.in-addr.arpa"
{
type slave;
file "db.192";
masters { 192.168.1.10; };
};


Zevendesoni 192.168.1.10 me adresen IP te serverit tuaj Primary .

Restartoni sherbimin named tek Secondary Master:


service named restart




Name server switch configuration

Menyra se si serveri Juaj ben perkthimin e emrave percaktohet ne skedarin /etc/nsswitch.conf.

Sjellja baze eshte qe permbajtja e skedarit /etc/hosts ka prioritet me pas tentohet te perdoret DNS.

Me poshte eshte nje shembull i skedarit /etc/nsswitch.conf

hosts: files dns


Skedari /etc/named.rfc1912.zone


// named.rfc1912.zones:
//
// Provided by Red Hat caching-nameserver package
//
// ISC BIND named zone configuration for zones recommended by
// RFC 1912 section 4.1 : localhost TLDs and address zones
// and http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt
// (c)2007 R W Franks
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//


zone "localhost.localdomain" IN {
type master;
file "named.localhost";
allow-update { none; };
};



zone "example.com" IN {
type slave;
file "example.com.db";
masters { 192.168.221.80; };
};


zone "endri.com" IN {
type slave;
file "endri.com.zone";
masters {192.168.221.80;};
};

zone "localhost" IN {
type master;
file "named.localhost";
allow-update { none; };
};


zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "named.loopback";
allow-update { none; };
};


zone "1.0.0.127.in-addr.arpa" IN {
type master;
file "named.loopback";
allow-update { none; };
};


zone "221.168.192.in-addr.arpa" IN {
type slave;
file "db.192";
masters { 192.168.221.80; };
};


zone "0.in-addr.arpa" IN {
type master;
file "named.empty";
allow-update { none; };
};



LAB - Intalimi i serverit DNS



Ne kete LAB ilustrohet instalimi dhe konfigurimi baze i nje serveri DNS

Instalimi i serverit DNS




Ne menyre qe te kapim sherbimin e
DNS Serverit nepermjet rrjetit duhet te ulim firewall.

# service iptables save
# service iptables stop
# chkconfig iptables off


Si funksionon sherbimi DNS (anglisht, artikull nga msdn)


When a DNS client needs to look up a name used in a program, it queries DNS servers to resolve the name. Each query message the client sends contains three pieces of information, specifying a question for the server to answer:

  • A specified DNS domain name, stated as a fully qualified domain name (FQDN)
  • A specified query type, which can either specify a resource record by type or a specialized type of query operation
  • A specified class for the DNS domain name (usually a  Internet (IN) class )
  • A name query begins at a client computer and is passed to a resolver, the DNS Client service, for resolution.
  • When the query cannot be resolved locally, DNS servers can be queried as needed to resolve the name.

For example, the name specified could be the FQDN for a computer, such as "host-a.example.microsoft.com.", and the query type specified to look for an address (A) resource record by that name. Think of a DNS query as a client asking a server a two-part question, such as "Do you have any A resource records for a computer named 'hostname.example.microsoft.com.'?" When the client receives an answer from the server, it reads and interprets the answered A resource record, learning the IP address for the computer it asked for by name.

DNS queries resolve in a number of different ways. A client can sometimes answer a query locally using cached information obtained from a previous query. The DNS server can use its own cache of resource record information to answer a query. A DNS server can also query or contact other DNS servers on behalf of the requesting client to fully resolve the name, then send an answer back to the client. This process is known as recursion.

In addition, the client itself can attempt to contact additional DNS servers to resolve a name. When a client does so, it uses separate and additional nonrecursive queries based on referral answers from servers. This process is known as iteration.

In general, the DNS query process occurs in two parts:

Both of these processes are explained in more detail in the following sections.

Part 1: The local resolver

The following figure shows an overview of the complete DNS query process.

How a DNS query works

As shown in the initial steps of the query process, a DNS domain name is used in a program on the local computer. The request is then passed to the DNS Client service for resolution using locally cached information. If the queried name can be resolved, the query is answered and the process is completed.

The local resolver cache can include name information obtained from two possible sources:

  • If a Hosts file is configured locally, any host name-to-address mappings from that file are preloaded into the cache when the DNS Client service is started.

  • Resource records obtained in answered responses from previous DNS queries are added to the cache and kept for a period of time.

If the query does not match an entry in the cache, the resolution process continues with the client querying a DNS server to resolve the name.

Part 2: Querying a DNS server

As indicated in the previous figure, the client queries a preferred DNS server. The actual server used during the initial client/server query part of the process is selected from a global list. For more information about how this global list is compiled and updated, see Client features.

When the DNS server receives a query, it first checks to see if it can answer the query authoritatively based on resource record information contained in a locally configured zone on the server. If the queried name matches a corresponding resource record in local zone information, the server answers authoritatively, using this information to resolve the queried name.

If no zone information exists for the queried name, the server then checks to see if it can resolve the name using locally cached information from previous queries. If a match is found here, the server answers with this information. Again, if the preferred server can answer with a positive matched response from its cache to the requesting client, the query is completed.

If the queried name does not find a matched answer at its preferred server -- either from its cache or zone information -- the query process can continue, using recursion to fully resolve the name. This involves assistance from other DNS servers to help resolve the name. By default, the DNS Client service asks the server to use a process of recursion to fully resolve names on behalf of the client before returning an answer. In most cases, the DNS server is configured, by default, to support the recursion process as shown in the following figure.

How recursion works

In order for the DNS server to do recursion properly, it first needs some helpful contact information about other DNS servers in the DNS domain namespace. This information is provided in the form ofroot hints, a list of preliminary resource records that can be used by the DNS service to locate other DNS servers that are authoritative for the root of the DNS domain namespace tree. Root servers are authoritative for the domain root and top-level domains in the DNS domain namespace tree. For more information, see Updating root hints.

By using root hints to find root servers, a DNS server is able to complete the use of recursion. In theory, this process enables any DNS server to locate the servers that are authoritative for any other DNS domain name used at any level in the namespace tree.

For example, consider the use of the recursion process to locate the name "host-b.example.microsoft.com." when the client queries a single DNS server. The process occurs when a DNS server and client are first started and have no locally cached information available to help resolve a name query. It assumes that the name queried by the client is for a domain name of which the server has no local knowledge, based on its configured zones.

First, the preferred server parses the full name and determines that it needs the location of the server that is authoritative for the top-level domain, "com". It then uses an iterative (that is, a nonrecursive) query to the "com" DNS server to obtain a referral to the "microsoft.com" server. Next, a referral answer comes from the "microsoft.com" server to the DNS server for "example.microsoft.com".

Finally, the "example.microsoft.com." server is contacted. Because this server contains the queried name as part of its configured zones, it responds authoritatively back to the original server that initiated recursion. When the original server receives the response indicating that an authoritative answer was obtained to the requested query, it forwards this answer back to the requesting client and the recursive query process is completed.

Although the recursive query process can be resource-intensive when performed as described above, it has some performance advantages for the DNS server. For example, during the recursion process, the DNS server performing the recursive lookup obtains information about the DNS domain namespace. This information is cached by the server and can be used again to help speed the answering of subsequent queries that use or match it. Over time, this cached information can grow to occupy a significant portion of server memory resources, although it is cleared whenever the DNS service is cycled on and off.

Alternate query responses

The previous discussion of DNS queries assumes that the process ends with a positive response returned to the client. However, queries can return other answers as well. These are the most common:

  • An authoritative answer

  • A positive answer

  • A referral answer

  • A negative answer

An authoritative answer is a positive answer returned to the client and delivered with the authority bit set in the DNS message to indicate the answer was obtained from a server with direct authority for the queried name.

A positive response can consist of the queried RR or a list of RRs (also known as an RRset) that fits the queried DNS domain name and record type specified in the query message.

A referral answer contains additional resource records not specified by name or type in the query. This type of answer is returned to the client if the recursion process is not supported. The records are meant to act as helpful reference answers that the client can use to continue the query using iteration.

A referral answer contains additional data such as resource records (RRs) that are other than the type queried. For example, if the queried host name was "www" and no A RRs for this name were found in this zone but a CNAME RR for "www" was found instead, the DNS server can include that information when responding to the client.

If the client is able to use iteration, it can make additional queries using the referral information in an attempt to fully resolve the name for itself.

A negative response from the server can indicate that one of two possible results was encountered while the server attempted to process and recursively resolve the query fully and authoritatively:

  • An authoritative server reported that the queried name does not exist in the DNS namespace.

  • An authoritative server reported that the queried name exists but no records of the specified type exist for that name.

The resolver passes the results of the query, in the form of either a positive or negative response, back to the requesting program and caches the response.


How iteration works

Iteration is the type of name resolution used between DNS clients and servers when the following conditions are in effect:

  • The client requests the use of recursion, but recursion is disabled on the DNS server.

  • The client does not request the use of recursion when querying the DNS server.

An iterative request from a client tells the DNS server that the client expects the best answer the DNS server can provide immediately, without contacting other DNS servers.

When iteration is used, a DNS server answers a client based on its own specific knowledge about the namespace with regard to the names data being queried. For example, if a DNS server on your intranet receives a query from a local client for "www.microsoft.com", it might return an answer from its names cache. If the queried name is not currently stored in the names cache of the server, the server might respond by providing a referral -- that is, a list of NS and A resource records for other DNS servers that are closer to the name queried by the client.

When a referral is made, the DNS client assumes responsibility to continue making iterative queries to other configured DNS servers to resolve the name. For example, in the most involved case, the DNS client might expand its search as far as the root domain servers on the Internet in an effort to locate the DNS servers that are authoritative for the "com" domain. Once it contacts the Internet root servers, it can be given further iterative responses from these DNS servers that point to actual Internet DNS servers for the "microsoft.com" domain. When the client is provided records for these DNS servers, it can send another iterative query to the external Microsoft DNS servers on the Internet, which can respond with a definitive and authoritative answer.

When iteration is used, a DNS server can further assist in a name query resolution beyond giving its own best answer back to the client. For most iterative queries, a client uses its locally configured list of DNS servers to contact other name servers throughout the DNS namespace if its primary DNS server cannot resolve the query.

How caching works

As DNS servers process client queries using recursion or iteration, they discover and acquire a significant store of information about the DNS namespace. This information is then cached by the server.

Caching provides a way to speed the performance of DNS resolution for subsequent queries of popular names, while substantially reducing DNS-related query traffic on the network.

As DNS servers make recursive queries on behalf of clients, they temporarily cache resource records (RRs). Cached RRs contain information obtained from DNS servers that are authoritative for DNS domain names learned while making iterative queries to search and fully answer a recursive query performed on behalf of a client. Later, when other clients place new queries that request RR information matching cached RRs, the DNS server can use the cached RR information to answer them.

When information is cached, a Time-To-Live (TTL) value applies to all cached RRs. As long as the TTL for a cached RR does not expire, a DNS server can continue to cache and use the RR again when answering queries by its clients that match these RRs. Caching TTL values used by RRs in most zone configurations are assigned the Minimum (default) TTL which is set used in the zone's start of authority (SOA) resource record. By default, the minimum TTL is 3,600 seconds (1 hour) but can be adjusted or, if needed, individual caching TTLs can be set at each RR.