«DNS и BIND»

4. Установка BIND

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

Тем из читателей, кто прилежно прочитал предыдущие главы, вероятно, не терпится обзавестись наконец-то работающим DNS-сервером. В этой главе мы расскажем, как это сделать. Давайте установим пару DNS-серверов. К тому же кто-то, быть может, посмотрел в оглавление и открыл книгу прямо на этой главе (как вам не стыдно!). Если вы принадлежите к последним, имейте в виду, что в этой главе используются концепции из предшествующих, и для дальнейшего чтения вам они должны быть полностью ясны.

Существует несколько факторов, влияющих на особенности установки DNS-серверов. Самый главный - тип доступа к Интернету: полный доступ (например, доступна служба FTP и узел ftp.rs.internic.net), ограниченный доступ (путь в сеть ограничен брандмауэром) либо вовсе никакого доступа. В этой главе подразумевается, что есть полный доступ, прочие же случаи обсуждаются к главе 11.

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

Наша зона

Наша выдуманная зона будет обслуживать колледж. Университет кинематографии занимается изучением всех аспектов киноиндустрии и разрабатывает новейшие способы (легального) распространения кинопродукции. Один из наиболее многообещающих проектов включает исследования по использованию IP в качестве транспорта для распространения фильмов. Посетив веб-сайт нашего регистратора, мы остановились на доменном имени movie.edu. Недавно полученный грант позволил нам подключиться к сети Интернет.

В Университете кинематографии в настоящее время существуют две Ethernet-сети, а также планы по добавлению еще одной или двух. Эти сети имеют сетевые номера 192.249.249/24 и 192.253.253/24. Часть нашей таблицы узлов содержит следующие записи:

127.0.0.1 localhost

# Это наши главные машины

192.249.249.2 shrek.movie.edu shrek
192.249.249.3 toystory.movie.edu toystory toys
192.249.249.4 monsters-inc.movie.edu monsters-inc mi

# Эти машины наводят ужас (или сами находятся
# в ужасающем состоянии), и скоро их предстоит заменить

192.253.253.2 misery.movie.edu misery
192.253.253.3 shining.movie.edu shining
192.253.253.4 carrie.movie.edu carrie

# Червоточина (wormhole) - выдуманное явление, которое позволяет осуществить
# мгновенную транспортировку космических путешественников на огромные
# расстояния; оно до сих пор не признано стабильным. Единственная разница
# между червоточинами и маршрутизаторами состоит в том, что маршрутизаторы
# не транспортируют пакеты мгновенно, и особенно наши маршрутизаторы.

192.249.249.1 wormhole.movie.edu wormhole wh wh249
192.253.253.1 wormhole.movie.edu wormhole wh wh253

Сама сеть изображена на рис.4.1.

Создание данных для зоны

Первый шаг в установке DNS-серверов для Университета - преобразовать таблицу узлов в эквивалентные зональные данные. В DNS-версии данные разбиты по нескольким файлам. Один из файлов содержит отображения имен узлов в адреса. Прочие файлы содержат отображения адресов обратно в имена. Поиск адреса для имени иногда называется прямым отображением (forward mapping), а поиск имени по адресу - обратным отображением (reverse mapping). Каждая сеть имеет собственный файл с данными для обратного отображения.

Рис.4.1 Сеть Университета кинематографии

В этой книге мы будем пользоваться следующим: файл, содержащий данные преобразования имен узлов в адреса, носит имя вида db.DOMAIN. Для домена movie.edu этот файл называется db.movie.edu. Соответственно файлы, содержащие данные преобразования адресов в имена узлов, носят имена вида dbAADDR, где ADDR - номер сети без последних нулей или маски сети. В нашем примере файлы будут называться db.192.249.249 и db.192.253.253; по одному файлу на каждую сеть. (Префикс db - это сокращение для базы данных, от англ. database). Этот набор файлов db.DOMAIN и dbAADDR мы будем называть файлами данных зоны. Существуют и другие файлы данных зоны: db.cache и db.127.0.0. Это своего рода нагрузка. Каждый DNS-сервер должен иметь такие файлы, и для каждого сервера они более или менее похожи.

Для того чтобы связать файлы данных зоны, DNS-серверу требуется файл настройки - в BIND 8 и 9 он обычно называется named.conf. Формат файлов данных зоны одинаков во всех реализациях DNS и называется форматом мастер-файла. Однако формат файлов настройки является специфичным для реализации DNS-сервера - в нашем случае для DNS-сервера BIND.

Файлы данных зоны

Большинство записей в файлах данных зоны называются RR-записями DNS. При поиске DNS не обращает внимания на регистр символов, так что имена в файлах данных зоны можно набирать в произвольном регистре, даже в смешанном. Мы практически всегда используем строчные буквы. Несмотря на то, что поиск нечувствителен к регистру символов, регистр сохраняется при возвращении результатов. Таким образом, если добавить к файлам данных зоны записи с именем Titanic. movie.edu, результаты поиска для titanic.movie.edu будут содержать эти записи, но с заглавной буквой «Т» в имени домена.

RR-записи должны начинаться с первой позиции строки. RR-записи в примерах, приводимых в этой книге, начинаются с первой позиции, а видимые отступы появляются из-за своеобразного форматирования книги. В RFC-документах по DNS RR-записи в примерах приводятся в определенном порядке. Многие люди следуют этому порядку (и мы не исключение), но такой порядок следования записей не является обязательным. Итак, выбранный порядок следования записей:

Из прочих записей в данной главе рассмотрены:

Те из читателей, кто имеет опыт общения с форматом мастер-файла, наверняка при виде наших данных произнесут «Было бы гораздо короче написать вот так...». Мы не используем сокращения при создании данных для зоны (во всяком случае поначалу), чтобы читатели до конца поняли полный синтаксис каждого типа RR-записи. Когда полная версия будет всем понятна, мы вернемся и «сожмем» наши файлы.

Комментарии
Файлы данных зоны легче читать, если они содержат комментарии и устые строки. Комментарии начинаются с символа точки с запятой (;) и заканчиваются концом строки. Как вы, вероятно, догадались, DNS-сервер игнорирует комментарии и пустые строки.

Установка стандартного значения TTL для зоны

Прежде чем начать создание файлов данных зоны, необходимо выяснить, какой версией BIND мы будем пользоваться. (Чтобы узнать, какая версия у вас, выполните команду named -v. Если ваша версия BIND не отзывается на эту команду, значит, она более старая, чем 8.2.) Версия имеет значение, поскольку способ задания стандартного значения времени жизни (TTL, time to live) для зоны изменился в BIND версии 8.2. В предшествующих версиях значение TTL по умолчанию определялось последним полем SOA-записи. Но непосредственно перед выходом BIND версии 8.2 был опубликован документ RFC 2308, который изменил значение последнего поля SOA-записи на время жизни отрицательного кэширования. Этот показатель определяет, как долго удаленные DNS-серверы имеют право сохранять информацию об отрицательных ответах, связанных с зоной, то есть ответах, суть которых заключается в том, что доменное имя или тип данных не существует в конкретном домене.

Как установить значение TTL по умолчанию в BIND 8.2 и более поздних? С помощью новой директивы - $TTL. $TTL позволяет указать время жизни для всех записей в файле, которые следуют за этой директивой (но предшествуют любым другим директивам $TTL) и не имеют явно заданного времени жизни.

Сервер имен передает указанное значение TTL вместе с ответами на запросы, что позволяет другим DNS-серверам кэшировать полученные данные на указанный интервал времени. Если данные изменяются не часто, разумным значением для времени жизни будет интервал в несколько дней. Неделя - наибольший разумный интервал. Можно использовать значение в несколько минут, но не рекомендуется использовать нулевой интервал из-за объема DNS-трафика, который он провоцирует.

$TTL 3h

Если используется DNS-сервер более старый, чем BIND версии 8.2, не пытайтесь использовать оператор $TTL, поскольку DNS-сервер его не опознает и посчитает за ошибку.

SOA-записи

Следующая часть в каждом из наших файлов - SOA-запись (RR-запись типа SOA). SOA-запись показывает, что данный DNS-сервер является самым надежным источником информации в пределах этой зоны. Наш DNS-сервер является авторитетным для зоны movie.edu по вкаждом файле db.DOMAIN и db.ADDR. В файле данных зоны может присутствовать одна и только одна SOA-запись.

Мы добавили следующую SOA-запись к файлу db.movie.edu:

movie.edu. IN SOA toystory.movie.edu. al.movie.edu. (

1       ;Порядковый номер
3h     ;Обновление через 3 часа
1h     ;Повторение попытки через 1 час
1w     ;Устаревание через 1 неделю
1h )   ;Отрицательное TTL в 1 час

Имя movie.edu. должно начинаться в первой позиции строки файла. Убедитесь, что имя заканчивается точкой, как в этом примере, иначе результат вас сильно удивит! (Чуть позже в этой главе мы объясним, как именно.)

Буквы IN обозначают Internet. Это один из классов данных - существуют и другие, но ни один из них в настоящее время широко не применяется. В наших примерах встречается только класс IN. Класс можно не указывать. Если класс не указан, DNS-сервер определяет его по выражению, диктующему чтение файла данных в файле настройки; чуть позже мы рассмотрим и это выражение.

Первое имя после SOA (toystory.movie.edu.) - это имя первичного DNS-сервера зоны movie.edu. Второе имя (al.movie.edu.) - это адрес электронной почты человека, управляющего зоной; чтобы использовать адрес, следует заменить первый символ « . » на символ « @ » . Часто можно увидеть имена root, postmaster или hostmaster в почтовых адресах.

Серверы имен не пользуются этими адресами, поскольку они предназначены для использования людьми. Если возникла проблема, имеющая отношение к зоне, всегда можно отправить сообщение по указанному почтовому адресу. BIND предоставляет для указания такого адреса специальный тип RR-записей - RP (responsible person, ответственное лицо). Записи типа R P рассматриваются в главе 7.

Скобки позволяют растягивать SOA-запись на несколько строк. Большинство полей в SOA-записи используются вторичными DNS-серверами, поэтому они будут нами изучены, когда мы дойдем до рассмотрения вторичных серверов в этой главе. Пока просто будем считать, что выбрали разумные значения полей.

Аналогичные SOA-записи мы добавляем в файлы db.192.249.249 и db.192.253.253. В этих файлах первое имя в SOA-записи изменяется с movie.edu. на имя соответствующей зоны in-addr.arpa: 249.249.192.inaddr. arpa. и 253. 253.192.in-addr.arpa.

NS-записи

movie.edu. IN NS toystory.movie.edu.
movie.edu. IN NS wormhole.movie.edu.

Эти записи указывают, что существует два DNS-сервера для зоны movie. edu. Серверы запущены на узлах toystory.movie.edu и wormhole.movie. edu. Узлы, входящие одновременно в несколько сетей, скажем wormhole.movie.edu, идеально подходят на роли DNS-серверов, поскольку имеют «правильное подключение». Такой узел напрямую доступен узлам более чем одной сети и находится под пристальным наблюдением со стороны администратора. Более подробно размещение DNS-серверов мы рассмотрим в главе 8.

Как и в случае с SOA-записью, NS-записи мы добавляем также к файлам db.192.249.249 и db.192.253.253.

RR-записи адресов и псевдонимов

;
; Адреса узлов
;
localhost.movie.edu. IN A 127.0.0.1
shrek.movie.edu. IN A 192.249.249.2
toystory.movie.edu. IN A 192.249.249.3
monsters-inc.movie.edu. IN A 192.249.249.4
misery.movie.edu. IN A 192.253.253.2
shining.movie.edu. IN A 192.253.253.3
carrie.movie.edu. IN A 192.253.253.4
;
; Жители нескольких сетей
;
wormhole.movie.edu. IN A 192.249.249.1
wormhole.movie.edu. IN A 192.253.253.1
;
; Псевдонимы
;
toys.movie.edu. IN CNAME toystory.movie.edu.
mi.movie.edu. IN CNAME monsters-inc.movie.edu.
wh.movie.edu. IN CNAME wormhole.movie.edu.
wh249.movie.edu. IN A 192.249.249.1
wh253.movie.edu. IN A 192.253.253.1

Первые два блока записей вряд ли кого-то удивят. Буква A обозначает адрес, а каждая RR-запись определяет отображение имени в соответствующий адрес. wormhole.movie.edu проживает сразу в нескольких сетях. Этот узел имеет два адреса, привязанных к имени, а следовательно, и две адресные записи. В отличие от поиска по таблице узлов, поиск DNS может возвращать несколько адресов для имени; так, поиск адреса wormhole.movie.edu возвращает два результата. Если автор запроса и DNS-сервер расположены в одной сети, некоторые DNS-серверы в целях повышения эффективности сетевого обмена возвращают более «близкий» адрес первым. Эта возможность носит название сортировки адресов и описана в главе 10. Если сортировка адресов неприменима, адреса подвергаются круговой перестановке между запросами, так что в последующих ответах они перечисляются в отличающемся порядке. Эта возможность называется круговой системой (round robin); она также будет подробно описана в главе 10.

Третий блок содержит псевдонимы таблицы узлов. Для первых трех псевдонимов мы создали CNAME-RR-записи (canonical names, записи канонических имен). Однако для двух других псевдонимов мы создали адресные записи (почему - расскажем через несколько строк).

CNAME-запись определяет отображение псевдонима в каноническое имя узла. Сервер имен работает с записями типа CNAME совершенно не так, как обычно происходит работа с псевдонимами из таблицы узлов. При поиске имени, если DNS-сервер находит CNAME-запись, то имя узла заменяется каноническим именем, после чего поиск продолжается уже для этого имени. К примеру, когда сервер обрабатывает запрос для имени wh.movie.edu, то находит CNAME-запись, которая указывает на wormhole.movie.edu. Сервер производит поиск wormhole.movie.edu и возвращает оба адреса.

Следует запомнить одну вещь, которая касается псевдонимов вроде toys.movie.edu: они никогда не должны появляться в правой части RR-записей. Иначе говоря, в части данных RR-записи следует всегда использовать канонические имена (скажем, toystory.movie.edu). Обратите внимание, что в свежесозданных NS-записях используются именно канонические имена.

Две последних записи призваны решить специфическую проблему. Предположим, что необходимо проверить работу одного из интерфейсов многосетевого узла, например wormhole.movie.edu. Одним из часто применяемых способов диагностики является использование ping в целях проверки рабочего состояния интерфейса. Если попытаться использовать ping для имени wormhole.movie.edu, DNS-сервер вернет оба адреса узла. ping использует первый адрес из списка. Но какой адрес является первым?

Если бы речь шла о таблице узлов, мы бы выбирали между именами wh249.movie.edu и wh253.movie.edu; и каждому имени соответствует единственный адрес этого узла. Чтобы получить эквивалентную возможность в DNS, не следует создавать псевдонимы (CNAME-записи) для wh249.movie.edu и wh253.movie.edu, т.к. это приведет к тому, что при поиске по псевдониму будут возвращаться оба адреса wormhole.movie. edu. Вместо этого следует использовать адресные записи. Таким образом, чтобы проверить работу интерфейса 192.253.253.1 на узле wormhole.movie.edu, мы выполняем команду ping wh253.movie.edu, поскольку это имя соответствует единственному адресу. То же справедливо и для wh249.movie.edu.

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

При этом не стоит рассказывать пользователям об именах wh249.movie. edu и wh253.movie.edu. Эти имена предназначены только для служебного использования. Если пользователи привыкнут использовать имена вроде wh249.movie.edu, у них возникнут проблемы, поскольку это имя будет работать не во всех контекстах (скажем, не будет работать для файлов .rhosts). Происходить это будет потому, что в некоторых контекстах требуется имя, которое является результатом поиска по адресу, то есть каноническое имя wormhole.movie.edu.

Мы использовали адресные (A) записи для создания псевдонимов wh249.movie.edu и wh253.movie.edu, и у читателей может возникнуть вопрос: «Можно ли использовать адресные записи вместо CNAME-записей во всех случаях?». У большинства приложений использование адресных записей вместо CNAME-записей затруднений не вызывает, поскольку их интересует только соответствующий IP-адрес. Но есть одно приложение, а именно sendmail, поведение которого изменяется. Sendmail обычно заменяет псевдонимы в заголовках почтовых сообщений соответствующими каноническими именами; и канонизация происходит только в том случае, если для имен, указанных в заголовке, существуют CNAME-данные. Если не использовать CNAME-записи для создания псевдонимов, приложению sendmail придется рассказать обо всех возможных псевдонимах, под которыми может быть известен узел, а это потребует дополнительных усилий по настройке sendmail.

Помимо проблем sendmail, проблемы могут возникать и у пользователей, которым понадобится выяснить каноническое имя узла для записи его в файл .rhosts. Поиск по псевдониму, для которого существует CNAME-запись, вернет каноническое имя, но если существует только адресная запись, этого не произойдет. В таком случае пользователям для получения канонического имени придется производить поиск по IP-адресу, как это делает программа rlogind, но такие умные пользователи никогда не встречаются в системах, которые мы администрируем.

PTR-записи

Теперь мы создадим отображения адресов в имена. Файл db.192.249.249 содержит отображения адресов в имена узлов для сети 192.249.249/24. Для такого отображения используются RR-записи DNS, которые носят название PTR-записей, или записей-указателей (pointer records). Для каждого сетевого интерфейса узла присутствует ровно одна запись. (Вспомним, что поиск по адресам в DNS - это, по сути дела, поиск по именам. Адрес инвертируется, и к нему добавляется имя inaddr.arpa.)

1.249.249.192.in-addr.arpa. IN PTR wormhole.movie.edu.
2.249.249.192.in-addr.arpa. IN PTR shrek.movie.edu.
3.249.249.192.in-addr.arpa. IN PTR toystory.movie.edu.
4.249.249.192.in-addr.arpa. IN PTR monsters-inc.movie.edu.

Здесь есть пара моментов, на которые стоит обратить внимание читателей. Во-первых, каждый адрес должен указывать на единственное имя - каноническое. Так, адрес 192.249.249.1 отображается в wormhole. movie.edu, но не в wh249.movie.edu. Допускается создание двух PTR-записей - одной для wormhole.movie.edu и одной для wh249.movie. edu, но большинство программ не способны увидеть более одного имени, соответствующего адресу. Во-вторых, несмотря на то что узел wormhole.movie.edu имеет два адреса, здесь указан только один из них. Это происходит потому, что файл отображает только адреса в сети 192.249.249/24, а узел wormhole.movie.edu имеет только один адрес в этой сети.

Аналогичные данные мы создаем для сети 192.253.253/24.

Полные файлы данных зоны

Итак, рассказав о различных типах RR-записей в файлах данных зоны, мы покажем, как эти файлы выглядят полностью. Вспомните, что порядок следования записей в действительности не имеет значения.

$TTL 3h
movie.edu. IN SOA toystory.movie.edu. al.movie.edu. (

1      ; Порядковый номер
3h    ; Обновление через 3 часа
1h    ;Повторение попытки через 1 час
1w    ; Устаревание через 1 неделю
1h )  ; Отрицательное TTL в 1 час

;
; Серверы имен
;
movie.edu. IN NS toystory.movie.edu.
movie.edu. IN NS wormhole.movie.edu.

;
; Адреса для канонических имен
;
localhost.movie.edu.       IN A 127.0.0.1
shrek.movie.edu.            IN A 192.249.249.2
toystory.movie.edu.        IN A 192.249.249.3
monsters-inc.movie.edu. IN A 192.249.249.4
misery.movie.edu.          IN A 192.253.253.2
shining.movie.edu.         IN A 192.253.253.3
carrie.movie.edu.           IN A 192.253.253.4
wormhole.movie.edu.     IN A 192.249.249.1
wormhole.movie.edu.     IN A 192.253.253.1

;
; Псевдонимы
;
toys.movie.edu.   IN CNAME toystory.movie.edu.
mi.movie.edu.      IN CNAME monsters-inc.movie.edu.
wh.movie.edu.     IN CNAME wormhole.movie.edu.

;
; Специальные имена интерфейсов
;
wh249.movie.edu.   IN A 192.249.249.1
wh253.movie.edu.   IN A 192.253.253.1

А вот содержимое файла db.192.249.249:

$TTL 3h
249.249.192.in-addr.arpa. IN SOA toystory.movie.edu. al.movie.edu. (

1 ;      Порядковый номер
3h ;    Обновление через 3 часа
1h ;    Повторение попытки через 1 час
1w ;    Устаревание через 1 неделю
1h ) ;  Отрицательное TTL в 1 час

;
; Серверы имен
;
249.249.192.in-addr.arpa. IN NS toystory.movie.edu.
249.249.192.in-addr.arpa. IN NS wormhole.movie.edu.

;
; Адреса, указывающие на канонические имена
;
1.249.249.192.in-addr.arpa. IN PTR wormhole.movie.edu.
2.249.249.192.in-addr.arpa. IN PTR shrek.movie.edu.
3.249.249.192.in-addr.arpa. IN PTR toystory.movie.edu.
4.249.249.192.in-addr.arpa. IN PTR monsters-inc.movie.edu.

А вот содержимое файла db.192.253.253:

$TTL 3h
253.253.192.in-addr.arpa. IN SOA toystory.movie.edu. al.movie.edu. (

1 ;      Порядковый номер
3h ;    Обновление через 3 часа
1h ;    Повторение попытки через 1 час
1w ;    Устаревание через 1 неделю
1h ) ;  Отрицательное TTL в 1 час

;
; Серверы имен
;
253.253.192.in-addr.arpa. IN NS toystory.movie.edu.
253.253.192.in-addr.arpa. IN NS wormhole.movie.edu.

;
; Адреса, указывающие на канонические имена
;
1.253.253.192.in-addr.arpa. IN PTR wormhole.movie.edu.
2.253.253.192.in-addr.arpa. IN PTR misery.movie.edu.
3.253.253.192.in-addr.arpa. IN PTR shining.movie.edu.
4.253.253.192.in-addr.arpa. IN PTR carrie.movie.edu.

Loopback-адрес

Серверу имен требуется еще один дополнительный файл db.ADDR для loopback-сети и специального адреса, который используется узлом для направления пакетов самому себе. Эта сеть (почти) всегда имеет номер 127.0.0/24, а адрес узла (почти) всегда - 127.0.0.1. Следовательно, файл имеет имя db.127.0.0. Что неудивительно, поскольку он похож на другие файлы db.ADDR.

Вот содержимое файла db.127.0.0:

$TTL 3h
0.0.127.in-addr.arpa. IN SOA toystory.movie.edu. al.movie.edu. (

1 ;      Порядковый номер
3h ;    Обновление через 3 часа
1h ;    Повторение попытки через 1 час
1w ;    Устаревание через 1 неделю
1h ) ;  Отрицательное TTL в 1 час

0.0.127.in-addr.arpa. IN NS toystory.movie.edu.
0.0.127.in-addr.arpa. IN NS wormhole.movie.edu.

1.0.0.127.in-addr.arpa. IN PTR localhost.

Зачем DNS-серверам нужен этот глупый маленький файл? Задумаемся на секунду. Никто не отвечает за сеть 127.0.0/24, но она используется многими системами в качестве loopback. Поскольку никто не отвечает за эту сеть, каждый отвечает за нее самостоятельно. Можно обойтись без этого файла, и DNS-сервер будет работать. Однако поиск по адресу 127.0.0.1 не даст положительных результатов, поскольку корневой DNS-сервер не был настроен таким образом, чтобы отображать адрес 127.0.0.1 в конкретное имя. Чтобы избежать сюрпризов, это отображение должен обеспечить администратор DNS-сервера.

Указатели корневых серверов

Помимо локальной информации, DNS-серверу также необходимо обладать информацией о DNS-серверах корневого домена. Эту информацию следует получить с интернет-узла ftp.rs.internic.net (198.41.0.6). Воспользуйтесь анонимным FTP-доступом, чтобы скопировать файл db.cache из подкаталога domain на этом сервере.

;    This file holds the information on root name servers needed to
;    initialize cache of Internet domain name servers
;    (e.g. reference this file in the "cache . "
;    configuration file of BIND domain name servers).
;
;    This file is made available by InterNIC
;    under anonymous FTP as
;    file            /domain/db.cache
;    on server   FTP.INTERNIC.NET
;  -OR-           RS.INTERNIC.NET
:
;   last update:  Jan 29, 2004
;   related version of root zone: 2004012900
:
;
; formerly NS.INTERNIC.NET
;
.                                       3600000   IN   NS   A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.  3600000          A     198.41.0.4
;
; formerly NS1.ISI.EDU
;
.                                      3600000          NS   B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000           A     192.228.79.201
;
; formerly C.PSI.NET
;
.                                      3600000         NS   C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000          A     192.33.4.12
;
; formerly TERP.UMD.EDU
;
.                                      3600000          NS   D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000           A     128.8.10.90
;
; formerly NS.NASA.GOV
;
.                                      3600000          NS   E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000           A     192.203.230.10
;
; formerly NS.ISC.ORG
;
.                                     3600000           NS   F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000           A     192.5.5.241
;
; formerly NS.NIC.DDN.MIL
;
.                                      3600000          NS  G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000           A   192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
.                                      3600000         NS  H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000          A    128.63.2.53
;
; formerly NIC.NORDU.NET

;
.                                      3600000         NS  I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.   3600000          A   192.36.148.17
;
; operated by VeriSign, Inc.
;
.                                      3600000         NS  J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.  3600000          A    192.58.128.30
;
; operated by RIPE NCC
;
.                                      3600000         NS  K. ROOT-SERVERS.NET.
K.ROOT.SERVERS.NET. 3600000          A    193.0.14.129
;
; operated by ICANN
;
.                                      3600000         NS  L.ROOT-SERVERS.NET.
L.ROOT.SERVERS.NET.  3600000         A    198.32.64.12
;

; operated by WIDE
;
.                                      3600000         NS  M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000          A   202.12.27.33
; End of File

Доменное имя « . » обозначает корневую зону. Поскольку серверы корневой зоны время от времени меняются, не стоит считать этот список соответствующим действительности. Воспользуйтесь последней версией файла db.cache.

Каким образом файл идет в ногу со временем? Это задача, которую выполняет сетевой администратор. Некоторые из более старых версий BIND умели периодически обновлять этот файл, но эта возможность в итоге была изъята, поскольку она, очевидно, не работала так, как задумали авторы. Время от времени измененный файл db.cache помещается в список рассылки bind-users или namedroppers, о которых мы рассказывали в главе 3. Если вы являетесь участником одного из этих списков, то, скорее всего, услышите об изменениях.

Можно ли помещать в этот файл данные, не относящиеся к корневым DNS-серверам? Можно, но эти данные не будут использоваться. Когда-то DNS-серверы помещали данные из этого файла в кэш. Использование файла изменилось (неуловимым образом), а имя «кэш-файл» осталось. Сервер имен хранит данные этого файла в специальной области памяти, которая известна как область корневых указателей (root hints). В отличие от кэшированных данных, указатели по истечении интервала TTL продолжают использоваться. Корневые указатели применяются DNS-сервером, чтобы запрашивать у корневых DNS-серверов текущий перечень корневых DNS-серверов, который уже кэшируется. Когда истекает интервал TTL для этого перечня, DNS-сервер повторяет процедуру и получает новый.

Зачем DNS-серверу посылать запрос DNS-серверу из списка корневых указателей - который, вероятно, сам является корневым DNS-сервером - на предмет получения списка корневых DNS-серверов, если такой список уже есть? Причина проста, DNS-сервер, которому посылается запрос, практически наверняка знает текущий список корневых DNS-серверов, тогда как файл может уже не соответствовать действительности.

Для чего нужны цифры 3600000? Это явным образом указанное время жизни записей файла в секундах. В более старых версиях этого файла использовалось число 99999999. Поскольку содержимое файла изначально кэшировалось, DNS-серверу необходимо было знать, как долго можно хранить записи. 99999999 секунд - это просто очень большой интервал времени, который позволял хранить данные в кэше на протяжении всего времени работы сервера. Поскольку DNS-сервер теперь хранит эти данные в специальной области данных и не удаляет их по истечении заданного интервала времени, TTL стали необязательными. Но иметь цифры 3600000 не помешает, и в случае передачи ответственности за сервер следующему администратору это может стать основой BIND-фольклора.