DNS-серверы и зоны

 в раздел Оглавление

«DNS и BIND»

Руководство для системных администраторов

2. Как работает DNS

DNS-серверы и зоны

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

Разбивка домена edu на зоны
Рис.2.8 Разбивка домена edu на зоны

Разница между зоной и доменом важна, но не очень заметна. Все домены высшего уровня и домены уровней от второго и ниже, такие как berkeley.edu и hp.com, разбиваются на более мелкие, легко управляемые единицы путем делегирования. Эти единицы называются зонами.

Домен edu (рис.2.8) разделен на много зон, включая зону berkeley.edu, зону purdue.edu и зону nwu.edu. На вершине домена существует также зона edu. Естественно, что ребята, управляющие edu, разбивают домен edu на более мелкие единицы: в противном случае им пришлось бы самим сопровождать поддомен berkeley.edu. Гораздо более разумно делегировать berkeley.edu Беркли. Что же остается тем, кто управляет edu? Зона edu, которая содержит преимущественно информацию о делегировании для поддоменов, входящих в edu.

Поддомен berkeley.edu, в свою очередь, разбивается на несколько зон путем делегирования (рис.2.9). Делегированные поддомены носят имена cc, cs, ce, me и т.д. Каждый из этих поддоменов делегируется ряду серверов имен, некоторые из которых являются компетентными и для berkeley.edu. Тем не менее зоны живут самостоятельно и могут иметь совершенно отдельный набор авторитетных DNS-серверов.

Разбивка домена berkeley.edu на зоны
Рис.2.9 Разбивка домена berkeley.edu на зоны

Зона включает все доменные имена, которые включает домен с тем же именем, за исключением доменных имен, принадлежащих к делегированным поддоменам. Так, домен высшего уровня ca (Канада) включает поддомены ab.ca, on.ca и qc.ca, относящиеся к провинциям Альберта, Онтарио и Квебек. Ответственность за сопровождение данных в поддоменах ab.ca, on.ca и qc.ca может быть делегирована серверам имен в каждой из этих провинций. Домен ca содержит всю информацию для ca, а также всю информацию в ab.ca, on.ca и qc.ca. Однако зона ca содержит данные только для ca (рис.2.10), и эти данные, вероятно, в основном являются указателями на делегированные поддомены. ab.ca, on.ca и qc.ca являются отдельными от ca зонами.

Домен ca...
Рис.2.10 Домен ca...

Зона также содержит имена доменов и данные всех поддоменов, которые не были делегированы. Так, поддомены bc.ca и sk.ca (Британская Колумбия и Саскачеван) домена ca могут существовать, но могут не быть делегированы. (Возможно, власти провинций Британская Колумбия и Саскачеван еще не готовы управлять собственными зонами, а люди, ответственные за зону высшего уровня ca, желают сохранить согласованность пространства имен и немедленно создать поддомены для всех провинций Канады.) В таком случае зона ca будет иметь неровную нижнюю границу, включая bc.ca и sk.ca, но не другие поддомены ca (рис.2.11).

... и зона ca
Рис.2.11 ... и зона ca

Теперь становится понятно, почему объектом, загружаемым DNS-сервером, является зона, а не домен: домен может содержать больше информации, чем требуется для работы сервера.[1] Домен может содержать данные, делегированные другим серверам. Поскольку зоны ограничиваются делегированием, они никогда не включают делегированные данные.

Обычно в начале существования у домена еще нет никаких поддоменов. В таком случае, поскольку делегирования не происходит, домен и зона содержат одинаковые данные.

Делегирование поддоменов

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

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

Разновидности DNS-серверов

Спецификация DNS определяет два типа DNS-серверов: первичный мастер-сервер (primary master) и дополнительный, или вторичный мастер-сервер (secondary master). Первичный мастер-сервер производит загрузку данных для зоны из файла на машине-сервере. Вторичный мастер-сервер получает данные зоны от другого DNS-сервера, который является авторитетным для этой зоны и называется его мастером (master server). Довольно часто мастер-сервер является первичным мастером для зоны, но не обязательно: вторичный мастер-сервер может получать зональные данные и от другого вторичного. Когда запускается вторичный сервер, он устанавливает связь с мастером и при необходимости получает зональные данные. Этот процесс называется передачей, или трансфером зоны (zone transfer). В наше время предпочтительным термином для вторичного мастер-сервера имен является slave (подчиненный, ведомый)1, хотя многие люди (и некоторые программы, в частности, консоль Microsoft DNS) все еще пользуются прежним термином.

Как первичный, так и вторичный мастер-серверы зоны являются для этой зоны авторитетными. Несмотря на несколько уничижительное название, вторичные (slave) серверы не являются серверами второго сорта. Эти два типа серверов предусмотрены в DNS с целью облегчения администрирования. После создания зональных данных и установки первичного мастера можно не беспокоиться о копировании данных с узла на узел при создании дополнительных DNS-серверов зоны. Достаточно просто установить вторичные DNS-серверы, которые будут получать данные от первичного мастер-сервера для этой зоны. После этого передача и получение зональных данных будут происходить по необходимости автоматически.

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

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

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

Файлы, из которых первичные DNS-серверы производят чтение зональных данных, называются, и вполне логично, файлами данных зоны. Мы достаточно часто называем их файлами данных. Вторичные DNS-серверы также могут загружать зональные данные из файлов. Обычно вторичные серверы настраиваются таким образом, что при каждом получении зональных данных с основного сервера происходит сохранение резервной копии полученной информации в файлах данных. При последующем перезапуске или сбое происходит сначала чтение файлов с резервных копий в целях определения актуальности зональных данных. Это позволяет устранить необходимость в передаче зональных данных, если они не изменились, и обеспечивает вторичный DNS-сервер рабочим набором данных в случае недоступности первичного сервера.

Файлы данных содержат RR-записи, описывающие зону. RR-записи описывают все узлы сети в зоне и помечают делегирование поддоменов. В BIND также существуют специальные директивы для включения содержимого других файлов данных в файл данных зоны аналогично директиве #include языка программирования C.


[1]Представьте, что получится, если корневой сервер имен загрузит корневой домен вместо зоны: он загрузит информацию обо всем пространстве имен!

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и абзацы переносятся автоматически.
CAPTCHA на основе изображений
Введите символы, которые показаны на картинке.