Практикум по администрированию программного обеспечения. Лабораторный практикум
.pdf
Лабораторный практикум 
ные с определенным доменом. Возможно редактирование описания зоны по условию.
Для того, чтобы успешно выполнялись обмены со slave-серве- рами, при каждом изменении зоны изменяется и номер ее версии. Это позволяет slave-серверам поддерживать свои описания зоны в актуальном, согласованном с Primary master-сервером состоянии.
Динамическое обновление описания зоны порождает другую проблему – многократную передачу по сети описания зоны между master-серверами и slave-серверами. Если описание зоны большое, то и объем трафика, который передается по сети, будет немаленький.
При этом стоит отметить, что собственно сами изменения описания зоны не столь и велики, т. к., например, при DHCP при каждом изменении добавляется/удаляется одна-две записи описания ресурсов. Каждое такое изменение будет порождать обмен описанием зоны.
При традиционном обмене описанием зоны (AXFR) Между master-сервером и slave-сервером передается полное описание зоны.
Для того, чтобы не передавать всю зону, а передавать только изменения предназначен механизм инкрементальной передачи описания зоны (IXFR, RFC-1995). В рамках обмена передаются номера версий описаний зон и записи, которые нужно добавить или удалить. Принцип простой – сначала идут номер старой версии и список записей, которые нужно удалить, а потом номер более свежей версии и записи, которые нужно добавить.
Мы более подробно остановимся на этом вопросе в разделе, посвященном настройкам BIND и файлам описания зон.
В контексте рассмотрения обмена описаниями зоны между master-серверами и slave-серверами следует упомянуть о «невидимых» серверах (stealth, см. RFC-1996). Суть такого сервера в том, что он не упоминается в описании зоны. Таким образом, его никто не видит, т. к. в рамках DNS-обмена данными информацию о нем получить нельзя ни путем простых запросов, ни путем копирования описания зоны.
Тем не менее, существуют еще файлы статической настройки (конфигурации) серверов доменных имен, где такой сервер может быть прописан. Его можно прописать в качестве master-сервера для slave или сконфигурировать таким образом, что он будет работать в качестве slave для конкретной зоны.
Для чего нужен такой невидимый сервер. Например, для того, чтобы вносить обновления в зону, находясь под защитой firewall.
71
Практикум по администрированию программного обеспечения
В этом случае Primary master можно сделать невидимым, а все остальные, в том числе и заявленные при регистрации домена, slave-серверами зоны. Это позволяет нейтрализовать атаки на зону, т. к. обновление всегда будет производиться с «невидимого»
Primary master (рис. 11.4).
Рис. 11.4. Схема организации DNS-серверов с невидимым primary master сервером
Другая причина создания «невидимых» серверов – разгрузка официально зарегистрированных серверов. В этом случае для обслуживания определенного класса клиентов, которые можно настроить на работу с «невидимым» сервером, создается один или несколько slave-серверов зоны. Они являются авторитативными, но неизвестными широкой интернет-общественности.
Рассмотрим еще один тип серверов, которые выделяют при описании системы доменных имен – кэширующие (cache) серверы. Этот тип серверов отличается от тех, что мы обсудили раньше, тем, что сервер данного типа не является авторитативным для ка- кой-либо зоны.
Серверы данного вида используют для организации централизованного кеширования соответствий доменных имен и IP-адре- сов. Идея организации кэширующего сервера состоит в том, чтобы на искать соответствие доменного имени и IP-адреса в сети, а накапливать их в своем локальном кэше и обслуживать оттуда запросы relover-ов.
72
Лабораторный практикум 
Кэш-сервер не поддерживает описаний зон и, соответственно, не посылает resolver-ам авторитативных откликов:
> www.w3.org
Server: [144.206.192.60]
Address: 144.206.192.60 Non-authoritative answer: Name: www.w3.org
Addresses: 18.29.1.35, 18.7.14.127, 18.29.1.34
>
Выше приведен типичный отклик кэширующего сервера на запрос nslookup об адресе www.w3.org. Если бы сервер был авторитативным, то строчки «Non-authoritative answer» в отклике мы бы не увидели.
Еще один тип серверов – серверы, которые обслуживают кор-
невую зону (Root servers). Их место в получении отклика на запрос к системе доменных имен ключевое. Именно к одному из корневых серверов обращается локальный сервер доменных имен, если не находит в зоне своей ответственности или в своем кэше соответствия между доменным именем и IP-адресом.
Список этих серверов можно получить достаточно просто. Ниже приведен отчет программы nslookup:
> .
Server: [144.206.192.60]
Address: 144.206.192.60 Non-authoritative answer: (root)
origin = A.ROOT-SERVERS.NET
mail addr = NSTLD.VERISIGN-GRS.COM serial = 2002091100
refresh = 1800 (30M) retry = 900 (15M) expire = 604800 (1W) minimum ttl = 86400 (1D)
Authoritative answers can be found from: (root) nameserver = A.ROOT-SERVERS.NET (root) nameserver = B.ROOT-SERVERS.NET (root) nameserver = C.ROOT-SERVERS.NET (root) nameserver = D.ROOT-SERVERS.NET (root) nameserver = E.ROOT-SERVERS.NET (root) nameserver = F.ROOT-SERVERS.NET (root) nameserver = G.ROOT-SERVERS.NET
73
Практикум по администрированию программного обеспечения
(root) nameserver = H.ROOT-SERVERS.NET (root) nameserver = I.ROOT-SERVERS.NET (root) nameserver = J.ROOT-SERVERS.NET (root) nameserver = K.ROOT-SERVERS.NET (root) nameserver = L.ROOT-SERVERS.NET (root) nameserver = M.ROOT-SERVERS.NET
A.ROOT-SERVERS.NET internet address = 198.41.0.4 B.ROOT-SERVERS.NET internet address = 128.9.0.107 C.ROOT-SERVERS.NET internet address = 192.33.4.12 D.ROOT-SERVERS.NET internet address = 128.8.10.90 E.ROOT-SERVERS.NET internet address = 192.203.230.10 F.ROOT-SERVERS.NET internet address = 192.5.5.241 G.ROOT-SERVERS.NET internet address = 192.112.36.4 H.ROOT-SERVERS.NET internet address = 128.63.2.53 I.ROOT-SERVERS.NET internet address = 192.36.148.17 J.ROOT-SERVERS.NET internet address = 198.41.0.10 K.ROOT-SERVERS.NET internet address = 193.0.14.129 L.ROOT-SERVERS.NET internet address = 198.32.64.12 M.ROOT-SERVERS.NET internet address = 202.12.27.33
>
Согласно этому отчету Primary master сервером для корневой зоны является серверA.ROOT-SERVERS.NET. Именно он отвечает за все изменения в описании зоны. Остальные серверы относительно корневой зоны являются slave-серверами. Slave-серверы обновляют свои описания зоны каждые 30 минут. Если в течении недели Primary master будет неработоспособен, то по идее вся система доменных имен потеряет связность. В RFC-2870, где описаны требования к работе root серверов, содержатся общие слова о том, как не допустить такого развития событий, но там нет конкретного плана действий.
На самом деле каждый из 13 серверов – это не одна машина. Так, например, k.root-servers.net (европейский) состоит из k1, k2 и k3, m.root-servers.net (японский) состоит из двух основных серверов и двух серверов горячего резерва, которые подключены к трем независимым точкаv обмена трафиком, f.root-servers.net состоит из двух двухпроцессорныхAlpha, по 4GB оперативной памяти в каждой, с балансировкой нагрузки через маршрутизатор Cisco.
И еще несколько слов о root серверах в заключении этого раздела. Существует такая организация – IEPG (Internet Operational Group), задача которой помогать сервис-провайдерам взаимодействовать в сети Интернет. В 1999 году на очередной встрече этой
74
Лабораторный практикум 
группы обсуждались проблемы DNS и приводилась некоторая статистика по запросам к root серверам:
Средние цифры таковы.
–Исходящий трафик – 600 Kbps.
–Входящий трафик – 2,2 Kbps.
–Число пакетов за сутки – 26M. Распределение запросов по типам:
–поиск IP-адреса(A) – 77 %;
–поиск сервера доменных имен (NS) – 15 %;
–поиск почтового шлюза (MX) – 5 %.
Статистика обслуживания запросов, которая названа ужасаю-
щей (Scary statistics):
1)только 26 % правильных (valid) запросов к корневой зоне;
2)в 6 % случаев на правильный запрос нельзя получить авторитативного отклика (.com, .net etc.);
3)66 % запросов к несуществующим доменам верхнего уровня
(non existent TLDs).
По поводу последней цифры автор BIND Paul Vixie предположил, что это обращения к группам Windows NT, и при отсутствии негативного кэширования в Windows эти запросы повторяются до 10 раз за секунду.
Приведенные цифры должны дать представление о степени нагрузки на root серверы и цену тиражировании программного обеспечения, содержащего неточности при реализации протоколов.
Так, в 2002 году на встрече IEGP также обсуждались проблемы DNS, а точнее масштаб ошибок при делегировании и описании зон.
Named – это сервер доменных имен пакета BIND. Named может реализовывать функции серверов любого типа: master, slave, cache.
Программа named в момент запуска или перезапуска считывает данные из своего файла конфигурации и файлов описания зон, если они существуют, и таким образом настраивается.
Конфигурационные параметры службы named хранятся в файлах каталога /etc/bind/, в первую очередь, в файле /etc/bind/named. conf.
/etc/bind/named.conf – Основной конфигурационный файл. Содержит значения конфигурационных параметров для всего сервера и включения других конфигурационных файлов.
named.conf.default-zones – Конфигурационный файл зон по умолчанию. В большинстве случаев не требует правки.
named.conf.options – Конфигурационный файл основных пара-
метров сервера, важным из которых является параметр directory,
75
Практикум по администрированию программного обеспечения
содержащий каталог конфигурационных файлов зон. Значение по умолчанию /var/cache/bind.
/etc/bind/named.conf.local – Конфигурационный файл описания локальных зон сервера. Для каждой зоны указываются пути к конфигурационным файлам для прямого и обратного разыменования (как правило, в указанном ранее каталоге /var/cache/bind).
Существует много способов настроить BIND9. Наиболее распространенные конфигурации – это кэширующий сервер имен, первичный мастер и вторичный мастер.
1.Когда BIND9 настроен как кэширующий сервер, он ищет ответы на запросы имени и запоминает ответ на случай, если запрос придет повторно.
2.В качестве первичного мастера BIND9 читает данные зоны из локального файла и является ответственным за эту зону.
3.В качестве вторичного мастера BIND9 получает данные по зоне (целиком) с другого сервера имен, отвечающего за эту зону.
Обзор. Файлы настройки DNS сохраняются в каталоге
/etc/bind. Основной файл конфигурации – это /etc/bind/named.conf.
Строки include определяют имена файлов, которые содержат
DNS опции. Строка directory в файле /etc/bind/named.conf.options
говорит DNS где искать файлы. Все файлы, используемые BIND, будут относительными к этому каталогу.
Файл с именем /etc/bind/db.root описывает корневые сервера имен в мире. Сервера со временем меняются, поэтому файл /etc/ bind/db.root должен обслуживаться сейчас и потом. Обычно это происходит в качестве обновления к пакету bind9. Секция zone определяет мастер сервер, и она сохранена в файле, определяемой опцией file.
Существует возможность настроить один сервер как кэширующий сервер имен, первичный мастер и вторичный мастер одновременно. Сервер может быть началом авторизации (SOA) для одной зоны, при этом предоставляя вторичный сервис для другой. И при всем этом предоставлять кэширующий сервис в локальной сети
(LAN).
Кэширующий сервер имен. По умолчанию конфигурация на-
страивается на работу кэширующим сервером. Все что для этого требуется – это добавить IP-адреса DNS серверов вашего интернет провайдера. Просто раскомментируйте и исправьте следую-
щее в /etc/bind/named.conf.options: forwarders {
1.2.3.4;
5.6.7.8;
};
76
Лабораторный практикум 
Замените 1.2.3.4 и 5.6.7.8 на актуальные IP-адреса серверов имен.
Теперь перегружаем DNS сервер для применения новой конфигурации. Наберите в терминале:
sudo service bind9 restart.
Смотрите dig для информации по тестированию кэширующего DNS сервера.
Первичный мастер. В этом разделе BIND9 будет настроен как первичный мастер для домена example.com. Просто замените example.com на ваше FQDN (квалифицированное имя домена).
Файл прямой зоны. Для добавления DNS зоны в BIND9, что превратит его в сервер первичного мастера, первым шагом отре-
дактируем /etc/bind/named.conf.local: zone «example.com» {
type master;
file «/etc/bind/db.example.com»; };
Теперь используем существующий файл зоны в качестве ша-
блона для создания файла /etc/bind/db.example.com: sudo cp /etc/bind/db.local /etc/bind/db.example.com.
Редактируем новый файл зоны /etc/bind/db.example.com, заменив localhost. на FQDN нашего сервера, оставляя дополнительную «.» в конце. Заменим 127.0.0.1 на IP-адрес сервера имен и root.localhost на правильный адрес email, но с «.» вместо символа «@», опять же оставляя «.» на конце. Замените комментарии для указания домена, для которого этот файл сделан.
Создайте A запись для базового домена example.com. Также создайте A запись для ns.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
;
77
Практикум по администрированию программного обеспечения
@IN NS ns.example.com.
@IN A 192.168.1.10
@IN AAAA ::1
ns IN A 192.168.1.10
Вы должны увеличивать Serial Number каждый раз, как делаете изменения в файле зоны. Если вы делаете множественные изменения, просто увеличьте Serial на единицу один раз перед перезапуском BIND9.
Теперь вы можете добавлять DNS записи в конец файла зоны. Многие администраторы предпочитают использовать дату последнегоредактированиявкачествеSerialзоныввиде2012010100, что соответствует формату yyyymmddss (где ss – Serial Number [за
день]).
Как только вы произвели изменения в файле зоны, требуется перегрузить BIND9 для применения изменений:
sudo service bind9 restart.
Файл обратной зоны. Теперь, поскольку зона создана и разрешает имена в IP-адреса, требуется создать также обратную зону. Обратная зона позволяет DNS определять имя по IP-адресу.
Редактируем /etc/bind/named.conf.local и добавляем следующее: zone «1.168.192.in-addr.arpa» {
type master;
file «/etc/bind/db.192»; };
Замените 1.168.192 на первые три октета адресов сети, которую вы используете. Также соответственно назовите файл зоны /etc/bind/db.192. В нем должен совпадать первый октет вашей сети.
Теперь создаем файл /etc/bind/db.192:
sudo cp /etc/bind/db.127 /etc/bind/db.192
Далее редактируем /etc/bind/db.192, изменяя в основном те же опции, что и в /etc/bind/db.example.com:
;
; 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
78
Лабораторный практикум 
;
@ IN NS ns.
10 IN PTR ns.example.com.
Serial Number в обратной зоне также требуется увеличивать при каждом изменении. Для каждой A записи, которую вы настроите в /etc/bind/db.example.com на другой адрес, вы должны создать запись PTR в /etc/bind/db.192.
После создания файла обратной зоны перегрузите BIND9: sudo service bind9 restart
Вторичный мастер. Поскольку первичный мастер настроен, требуется вторичный мастер для того, чтобы поддерживать домен при недоступности первичного мастера.
Для начала на первичном мастере надо разрешить передачу зоны. Добавьте опцию allow-transfer к определениям прямой и об-
ратной зон в /etc/bind/named.conf.local: zone «example.com» {
type master;
file «/etc/bind/db.example.com»; allow-transfer { 192.168.1.11; }; };
zone «1.168.192.in-addr.arpa» { type master;
file «/etc/bind/db.192»; allow-transfer { 192.168.1.11; }; };
Замените 192.168.1.11 на IP-адрес вашего вторичного сервера имен.
Перезапустим BIND9 на первичном мастере: sudo service bind9 restart.
Далее, на вторичном мастере установите пакет bind9 так же, как делали на первичном. Затем отредактируем /etc/bind/named. conf.local и добавим следующие определения к прямой и обратной зонам:
zone «example.com» { type slave;
file «db.example.com»; masters { 192.168.1.10; }; };
zone «1.168.192.in-addr.arpa» { type slave;
79
Практикум по администрированию программного обеспечения
file «db.192»;
masters { 192.168.1.10; }; };
Замените 192.168.1.10 на IP-адрес вашего первичного сервера имен.
Перегружаем BIND9 на вторичном мастере: sudo service bind9 restart.
В /var/log/syslog вы сможете увидеть нечто похожее на (некоторые строки разделены для соответствия формату документа):
client 192.168.1.10#39448: received notify for zone ‘1.168.192.inaddr.arpa’
zone 1.168.192.in-addr.arpa/IN: Transfer started.
transfer of ‘100.18.172.in-addr.arpa/IN’ from 192.168.1.10#53: connected using 192.168.1.11#37531
zone 1.168.192.in-addr.arpa/IN: transferred serial 5
transfer of ‘100.18.172.in-addr.arpa/IN’ from 192.168.1.10#53: Transfer completed: 1 messages,
6 records, 212 bytes, 0.002 secs (106000 bytes/sec) zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 5)
client 192.168.1.10#20329: received notify for zone ‘example.com’ zone example.com/IN: Transfer started.
transfer of ‘example.com/IN’ from 192.168.1.10#53: connected using 192.168.1.11#38577
zone example.com/IN: transferred serial 5
transfer of ‘example.com/IN’ from 192.168.1.10#53: Transfer completed: 1 messages,
8 records, 225 bytes, 0.002 secs (112500 bytes/sec)
Обратите внимание, что передача зоны произойдет только если Serial Number на первичном сервере больше значения на вторичном. Если вы хотите, чтобы первичный мастер DNS сообщал вторичному DNS серверу об изменении зоны, вы можете добавить also-notify { ipaddress; }; в /etc/bind/named.conf.local как показано в примере ниже:
zone «example.com» { type master;
file «/etc/bind/db.example.com»; allow-transfer { 192.168.1.11; }; also-notify { 192.168.1.11; };
};
zone «1.168.192.in-addr.arpa» { type master;
80