Серверы Linux. Часть III. Сервер DNS

Глава 4. Вводная информация о серверах DNS

4.10. Кэш DNS

Протокол DNS предусматривает кэширование данных.

В том случае, если клиент отправляет запрос локальному серверу DNS, который не обладает необходимой информацией для ответа на него, локальный сервер будет осуществлять поиск в в рамках дерева серверов DNS сервера, обладающего необходимой информацией. Локальный сервер имен начнет поиск сервера с отправки запроса корневому серверу, после чего перейдет к серверу, обслуживающему домен верхнего уровня и в конце концов обменяется данными с сервером, обслуживающим интересующий домен. После того, как локальный сервер имен получит информацию для ответа на запрос, он передаст эту информацию отправившему запрос клиенту, а также сохранит копию данных в своем кэше. Благодаря этому в случае отправки идентичного запроса этим же или другим клиентом этому же серверу имен, необходимая информация будет извлекаться уже из кэша сервера.

Рассмотрим пример, в котором клиент отправляет запрос на получение данных ресурсной записи A домена www.linux-trianing.be локальному серверу имен. Это первый подобный запрос, принятый данным локальным сервером имен. Локальный сервер имен установит, что он не обладает информацией о данном домене, как и сервер имен, обслуживающий домен верхнего уровня .be, и корневой сервер. В результате сервер имен использует информацию от корневого сервера для отправки итеративного запроса.

Корневой сервер DNS отправит ссылку на сервер, который обслуживает домен верхнего уровня .be (корневые серверы DNS не осуществляют разрешение полностью определенных доменных имен, а также не отвечают на рекурсивные запросы).

После этого локальный сервер имен отправит итеративный запрос серверу, обслуживающему домен верхнего уровня .be. Этот сервер отправит в ответ ссылку на сервер имен, который обладает информацией о домене linux-training.be.

После получения ссылки на сервер DNS, обладающий информацией о домене, локальный сервер имен отправит запрос информации о домене www.linux-training.be на этот сервер (или один из ведомых серверов, работающих с этим сервером). После того, как локальный сервер DNS получит IP-адрес, соответствующий домену www.linux-training.be, он отправит его клиенту, от которого был принят запрос.

Помимо кэширования данных ресурсной записи A домена www.linux-training.be, локальный сервер DNS также добавит в кэш данные ресурсных записей NS и A сервера имен домена linux-training.be, а также сервера имен домена верхнего уровня .be.

4.11. Пример настройки зоны DNS

Процесс настройки зоны DNS заключается в создании записи для зоны DNS в файле конфигурации /etc/bind/named.conf.local со ссылкой на другой файл (который является базой данных зоны).

Ниже приведен пример упомянутой записи из файла конфигурации /etc/bnd/named.conf.local.

root@debian7:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

zone "paul.local" IN {
        type master;
        file "/etc/bind/db.paul.local";
        allow-update { none; };
};
root@debian7:~#

Для создания файла базы данных зоны DNS может быть использован простой метод, заключающийся в копировании и редактировании файла базы данных уже существующей зоны DNS (что гораздо проще создания данного файла с нуля).

root@debian7:/etc/bind# cp db.empty db.paul.local
root@debian7:/etc/bind# vi db.paul.local

А это пример файла базы данных зоны DNS.

root@debian7:/etc/bind# cat db.paul.local
; zone for classroom teaching
$TTL    86400
@       IN      SOA     debianpaul.paul.local. root.paul.local (
                        2014100100      ; Serial
                        1h              ; Refresh
                        1h              ; Retry
                        2h              ; Expire
                        86400 )         ; Negative Cache TTL
;
; name servers
;
        IN      NS      ns1
        IN      NS      debianpaul
        IN      NS      debian7
;
; servers
;
debianpaul      IN      A       10.104.33.30
debian7         IN      A       10.104.33.30
ns1             IN      A       10.104.33.30
;www            IN      A       10.104.33.30

4.12. Пример: создание кэширующего сервера DNS

1. Установите программные компоненты сервера DNS в дистрибутиве Debian.

root@debian7:~# aptitude update && aptitude upgrade
...
root@debian7:~# aptitude install bind9
...
root@debian7:~# dpkg -l | grep bind9 | tr -s ' '
ii bind9 1:9.8.4.dfsg.P1-6+nmu2+deb7u2 amd64 Internet Domain Name Server
ii bind9-host 1:9.8.4.dfsg.P1-6+nmu2+deb7u2 amd64 Version of 'host' bundled...
ii bind9utils 1:9.8.4.dfsg.P1-6+nmu2+deb7u2 amd64 Utilities for BIND
ii libbind9-80 1:9.8.4.dfsg.P1-6+nmu2+deb7u2 amd64 BIND9 Shared Library use...
root@debian7:~#

2. Исследуйте используемые по умолчанию конфигурационные файлы сервера DNS. Можете ли вы дать пояснения относительно предназначения каждого из этих файлов?

root@debian7:~# ls -l /etc/bind
итого 52
-rw-r--r-- 1 root root 2389 сен  5 20:25 bind.keys
-rw-r--r-- 1 root root  237 сен  5 20:25 db.0
-rw-r--r-- 1 root root  271 сен  5 20:25 db.127
-rw-r--r-- 1 root root  237 сен  5 20:25 db.255
-rw-r--r-- 1 root root  353 сен  5 20:25 db.empty
-rw-r--r-- 1 root root  270 сен  5 20:25 db.local
-rw-r--r-- 1 root root 3048 сен  5 20:25 db.root
-rw-r--r-- 1 root bind  463 сен  5 20:25 named.conf
-rw-r--r-- 1 root bind  490 сен  5 20:25 named.conf.default-zones
-rw-r--r-- 1 root bind  374 окт  1 20:01 named.conf.local
-rw-r--r-- 1 root bind  913 окт  1 13:24 named.conf.options
-rw-r----- 1 bind bind   77 окт  1 11:14 rndc.key
-rw-r--r-- 1 root root 1317 сен  5 20:25 zones.rfc191

3. Настройте кэширующий сервер DNS. Режим кэширования запросов является стандартным режимом работы сервера, используемым по умолчанию. После настройки кэширующий сервер DNS будет осуществлять разрешение доменных имен и сохранять в кэше полученные данные. Во многих руководствах даются рекомендации относительно использования перенаправляющего сервера DNS, но в данном примере мы попытаемся организовать работу сервера DNS без него!

Оказывается, кэширующий сервер DNS может работать и без перенаправляющего сервера DNS! Вы можете воспользоваться сниффером для ознакомления с ходом процесса обмена данным при разрешении доменных имен. Только что установленный вами сервер DNS не будет использовать кэш, а также данные из файла конфигурации (/etc/resolv.conf) вашей локальной системы. Но откуда же тогда он получает информацию? И что вы можете узнать в процессе перехвата трафика протокола DNS?

4. Опишите в подробностях процессы, происходящие при использовании кэширующего сервера DNS без перенаправляющего сервера DNS. Хотя представленный ниже снимок окна сниффера Wireshark и может оказаться полезным, вы можете узнать гораздо больше, самостоятельно перехватывая и анализируя трафик протокола DNS.

Вы должны обнаруживать трафик по направлению к корневому серверу имен каждый раз при разрешении нового имени домена верхнего уровня. Помните о том, что протокол DNS предусматривает кэширование, следовательно, при повторении запроса будет генерироваться гораздо меньший объем трафика, ведь ваш сервер DNS хранит ответ на ранее полученный запрос в памяти.

4.13. Пример: настройка кэширующего сервера DNS для работы с перенаправляющим сервером DNS

5. Используйте адрес общедоступного сервера DNS компании Google в качестве адреса перенаправляющего сервера DNS. IP-адресом данного сервера является адрес 8.8.8.8.

Секция описания перенаправляющего сервера DNS файла конфигурации сервера DNS до внесения изменений:

root@debian7:~# grep -A2 'forwarders {' /etc/bind/named.conf.options
        // forwarders {
        //      0.0.0.0;
        // };

Команда для изменения данного файла:

root@debian7:~# vi /etc/bind/named.conf.options

Секция описания перенаправляющего сервера DNS файла конфигурации сервера DNS после внесения изменений:

root@debian7:~# grep -A2 'forwarders {' /etc/bind/named.conf.options
         forwarders {
                8.8.8.8;
         };

Команда для перезапуска службы сервера DNS:

root@debian7:~# service bind9 restart
Stopping domain name service...: bind9.
Starting domain name service...: bind9.

6. Дайте пояснения относительно целей использования перенаправляющего сервера DNS. Что делает наш сервер DNS после получения запроса?

root@debian7:~# nslookup
> server
Default server: 10.104.33.30
Address: 10.104.33.30#53
> linux-training.be
Server:         10.104.33.30
Address:        10.104.33.30#53

Non-authoritative answer:
Name:   linux-training.be
Address: 188.93.155.87
>

Ниже приведен фрагмент вывода команды tcpdump udp port 53, генерируемый при использовании упомянутой выше утилиты nslookup для получения информации о домене linux-training.be.

root@debian7:~# tcpdump udp port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

Вы должны обнаружить две следующие строки в выводе утилиты tcpdump:

10.104.33.30.19381 > google-public-dns-a.google.com.domain: 18237+% [1au] A? \
linux-training.be. (46)
google-public-dns-a.google.com.domain > 10.104.33.30.19381: 18237 1/0/1 A 188\
.93.155.87 (62)

Ниже приведен достаточно старый снимок окна сниффера Wireshark, который может оказаться полезным, причем в случае самостоятельного перехвата трафика вы должны будете увидеть информацию об аналогичных пакетах (но IP-адреса будут отличаться).

7. Что случится, если вы отправите запрос для получения информации об этом же доменном имени еще раз?

8. Почему в выводе утилиты присутствует информация об "неавторитативном ответе" (non-authoritative answer)? В каком случае сервер является авторитативным?

9. Вы можете использовать утилиту dig вместо утилиты nslookup.

root@debian7:~# dig @10.104.33.30 linux-training.be +short
188.93.155.87
root@debian7:~#

10. Как мы можем избежать указания IP-адреса сервера DNS при использовании утилиты dig или nslookup?

Достаточно изменить содержимое данного конфигурационного файла:

root@debian7:~# cat /etc/resolv.conf
nameserver 10.46.101.1
root@debian7:~#

Следующим образом:

root@debian7:~# cat /etc/resolv.conf
nameserver 10.104.33.30
root@debian7:~#

11. Откуда утилита dig получает информацию при разрешении доменного имени в первый раз? А во второй раз? Что вы думаете по этому поводу?