RFC-1034. Система именовния сегментов/областей. Концепция и общая характеристика (DNS). Ноябрь 1987 года (категория: стандарт)
Подождите немного. Документ загружается.
конфигурационного файла, который содержит список DNS-серверов,
считающихся более надежными. Несмотря на наличие ряда специфических
ситуаций, как правило, обычный выбор предусматривает отбор двух корневых
серверов и двух серверов, обслуживающих запрашиваемый сегмент/область.
Причина (избыточности) того, что опрашивается пара каждого типа серверов,
вполне очевидна, гарантированность получения ответа на запрос. Корневые
DNS-серверы будут обеспечивать окончательный доступ ко всему
пространству сегмента/области. Два локальных DNS-сервера позволят DNS-
клиенту продолжать принимать решения относительно локальных DNS-имен,
если вдруг локальная сеть, стала изолированной от Internet, вследствие
применения шлюза или разрыва соединения.
Помимо имен и адресов серверов, структура данных “SLIST” может быть
составлена таким образом, чтобы “наилучшие” DNS-серверы указывались
первыми и, следовательно, гарантировать, что все адреса всех DNS-серверов
будут использоваться циклически. Составление списка может представлять
собой простую процедуру, в основе которой лежит критерий
предпочтительности адреса той или иной локальной сети по отношению к
другим, либо это может быть вероятностное распределение на основе
последних статистических данных, таких как время предшествующего ответа и
усредненная частота поступлений ответов.
На третьей итерации рассылаются запросы, причем до тех пор, пока не
будет получены ответы. Сущность общей стратегии рассылки заключается в
циклической процедуре отправки запросов по всем найденным адресам все
DNS-серверов с использованием режима “тайм-аута” между каждой отправкой.
На практике чрезвычайно важно использовать все адреса многоканального IP-
узла, а слишком жесткая стратегия повторной передачи заметно замедляет
ответ, когда используются несколько DNS-клиентов, “соперничающих” за один
и тот же DNS-сервер, что бывает весьма редко при использовании одного DNS-
клиента. Данные в “SLIST” обычно содержат параметры для управления
режимом тайм-аута и информацию о маршруте предшествующих переданных
сообщений.
На четвертой итерации анализируются полученные ответные сообщения.
DNS-клиент должен обладать высокой производительностью, чтобы проводить
эффективный анализ поступающих ответных сообщений. Он также должен
проверять в полученном ответном сообщении специальное поле “ID”
(“идентификатор”), которое должно совпадать с аналогичным полем в
отправленном ранее сообщении-запросе.
Идеальным ответом DNS-сервера на принятый им запрос является ответ с
авторизованными данными, который может содержать либо запрашиваемую
информацию, либо сообщение об ошибке. Это ответное сообщение передается
41
DNS-клиентом пользователю и одновременно с этим размещается в кэш-памяти
для дальнейшего использования, если конечно время “TTL” больше нуля.
Если в ответе указано перенаправление запроса, то тогда DNS-клиент
должен проверить является ли новый предложенный DNS-сервер (с новым
адресом) для запроса более близким, чем те DNS-серверы, которые указаны в
перечне “SLIST”. Такую проверку можно осуществить путем сравнения
значений в “SLIST” с теми значениями, которые вычислены на основании
данных из “SNAME” и в записи о новом предложенном DNS-сервере (для
перенаправления запроса). Если результат отрицательный (то есть
предлагаемый DNS-сервер не является более близким, чем те, которые указаны
в перечне “SLIST”) то тогда ответ считается фиктивным, и он должен быть
проигнорирован. Если результат положительный, то тогда записи о новом
предложенном DNS-сервере и все любые другие адреса для серверов должны
быть размещены в кэш-памяти. Новые предложенные DNS-серверы заносятся в
перечень “SLIST”, а поиск возобновляется. Если ответ содержит каноническое
имя CNAME, то тогда поиск возобновляется в соответствии с этим CNAME до
тех пор, пока ответное сообщение не будет содержать данные об этом
каноническом имени, либо не будет получен ответ от владельца этого CNAME.
Рис.2. Пример функционирования DNS-системы
V
V
. ПРИМЕР ФУНКЦИОНИРОВАНИЯ
. ПРИМЕР ФУНКЦИОНИРОВАНИЯ
DNS
DNS
-СИСТЕМЫ
-СИСТЕМЫ
Для рассмотрения функционирования DNS-системы воспользуемся
пространством DNS-имен, представленным на рис.1. Полагаем, что зоны с
42
MIL ARPAEDU
DARPANOSCBRL SRI-NICIN-ADDR ACC
UCI MIT ISI UDEL YALE
LCS ACHILLES
AXX C VAXA VENERA Mockapetris
(C.ISI.EDU, SRI-NIC.ARPA,
A.ISI.EDU)
(SRI-NIC.ARPA,
A.ISI.EDU)
(SRI-NIC.ARPA,
C.ISI.EDU)
(VAXA.ISI.EDU, VENERA.ISI.EDU,
A.ISI.EDU)
(XX.LCS.MIT.EDU,
ACHILLES.MIT.EDU)
Авторизованные
серверы
именами “root”, “MIL”, “EDU”, “MIT.EDU” и “ISI.EDU” имеют собственные
административные системы управление. На рис.2 представлены DNS-серверы,
которые имеют собственное обозначение. В данном примере (рис.2),
авторизованный DNS-сервер обозначен именем в круглых скобках и его имя
размещено в той точке древовидной иерархической структуры, с которой
начинается его зона ответственности.
Таким образом, корневыми DNS-серверами являются серверы “ISI.EDU”,
“SRI-NIC.ARPA” и “A.ISI.EDU”. Сегмент “MIL” обслуживается серверами
“SRI-NIC.ARPA” и “A.ISI.EDU”. Сегмент “EDU” обслуживается серверами
“SRI-NIC.ARPA” и “C.ISI.EDU”. (Замечание. Серверы могут иметь зоны,
которые являются смежными или несвязными. В рассматриваемом
примере, “C.ISI.EDU” имеет смежные зоны в корневом и “EDU” сегментах.
“A.ISI.EDU” имеет смежные зоны в корневом и “MIL” сегментах, а также
несмежную зону в “ISI.EDU” сегменте.)
5.1. Характеристика DNS -сервера “ C . ISI . EDU ”
Данный сервер “C.ISI.EDU” является DNS-сервером для корневого,
“MIL” и “EDU” сегментов класса “IN” (Internet) и может иметь зоны в этих
сегментах. Зональные данные для корневого сегмента могут быть следующими:
. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
870611 ;serial
1800 ;refresh every 30 min
300 ;retry every 5 min
604800 ;expire after a week
86400) ;minimum of a day
NS A.ISI.EDU.
NS C.ISI.EDU.
NS SRI-NIC.ARPA.
MIL. 86400 NS SRI-NIC.ARPA.
86400 NS A.ISI.EDU.
EDU. 86400 NS SRI-NIC.ARPA.
86400 NS C.ISI.EDU.
SRI-NIC.ARPA. A 26.0.0.73
A 10.0.0.51
MX 0 SRI-NIC.ARPA.
HINFO DEC-2060 TOPS20
ACC.ARPA. A 26.6.0.65
HINFO PDP-11/70 UNIX
MX 10 ACC.ARPA.
USC-ISIC.ARPA. CNAME C.ISI.EDU.
73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
65.0.6.26.IN-ADDR.ARPA. PTR ACC.ARPA.
51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
52.0.0.10.IN-ADDR.ARPA. PTR C.ISI.EDU.
103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
43
A.ISI.EDU. 86400 A 26.3.0.103
C.ISI.EDU. 86400 A 10.0.0.52
Эти данные представлены таким образом, если бы они размещались в
мастер-файле. Большинство записей представлено в одну строку.
Единственным исключением здесь является запись “SOA”, которая использует
символы “скобки” [“(” и “)”] для указания начала многострочной записи [“(”] и
ее завершения [“)”]. Так как класс всех записей в зоне должен быть
одинаковым, то только первая запись должна содержать идентификатор класса
записей. Когда DNS-сервер содержит зональные данные, то тогда он в
принудительном порядке изменяет TTL во всех авторизованных записях,
которое должно быть равно, по крайней мере, значению, указанному в поле
“Minimum” записи “SOA” (в рассматриваемом примере — 86400 сек или один
день). Записи о новом DNS-сервере (обозначенные как данные
перенаправления) из “MIL” и “EDU” сегментов совместно с добавленными
(“glue”) записями, содержащими IP-адреса узлов, не являются
авторизованными данными в зоне и, следовательно, имеют точные значения
TTL.
Четыре записи закреплены за корневым узлом: запись “SOA”, которая
определяет корневую зону, и три записи о DNS-серверах, содержащие серверы
обслуживающие корневую зону. Данные в записи “SOA” определяют
управление в зоне. Зональные данные хранятся в DNS-сервере “SRI-
NIC.ARPA”, а ответственным “лицом” в зоне является “HOSTMASTER@SRI-
NIC.ARPA”. Ключевым элементом в записи “SOA” является минимальное TTL
со значением 86400 сек, которое означает, что все авторизованные данные в
зоне имеют, по крайней мере, такое значение TTL, несмотря на то, что верхние
значения могут быть определены точно.
Записи для “MIL” и “EDU” сегментов обозначают границу между
корневой зоной и “MIL” и “EDU” зонами. (Замечание. В представленном
примере, низшие зоны обслуживаются теми же серверами, которые
обслуживают корневую зону.)
Мастер-файл для “EDU” зоны может быть сформирован как файл,
который связан с оригинальным файлом “EDU” зоны. Зональные данные для
“EDU” сегмента могут быть следующими:
EDU. IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
870729 ;serial
1800 ;refresh every 30 minutes
300 ;retry every 5 minutes
604800 ;expire after a week
86400 ;minimum of a day
)
NS SRI-NIC.ARPA.
NS C.ISI.EDU.
UCI 172800 NS ICS.UCI
172800 NS ROME.UCI
44
ICS.UCI 172800 A 192.5.19.1
ROME.UCI 172800 A 192.5.19.31
ISI 172800 NS VAXA.ISI
172800 NS A.ISI
172800 NS VENERA.ISI.EDU.
VAXA.ISI 172800 A 10.2.0.27
172800 A 128.9.0.33
VENERA.ISI.EDU. 172800 A 10.1.0.52
172800 A 128.9.0.32
A.ISI 172800 A 26.3.0.103
UDEL.EDU. 172800 NS LOUIE.UDEL.EDU.
172800 NS UMN-REI-UC.ARPA.
LOUIE.UDEL.EDU. 172800 A 10.0.0.96
172800 A 192.5.39.3
YALE.EDU. 172800 NS YALE.ARPA.
YALE.EDU. 172800 NS YALE-BULLDOG.ARPA.
MIT.EDU. 43200 NS XX.LCS.MIT.EDU.
43200 NS ACHILLES.MIT.EDU.
XX.LCS.MIT.EDU. 43200 A 10.0.0.44
ACHILLES.MIT.EDU. 43200 A 18.72.0.8
(Замечание. Здесь используются связанные имена. Имя владельца
сегмента “ISI.EDU” сформировано с использованием связанного с ним
имени, так как существуют две формы записей о DNS-серверах.
Абсолютные и связанные с ними имена сегментов/областей могут быть
“перемешаны” в “мастер-файле”.)
5.2. Примеры стандартных запросов
Рассматриваемые далее запросы и ответы иллюстрируют процесс
функционирования DNS-сервера. За исключением особо оговариваемых,
запросы не требует рекурсии при формировании заголовка. (Замечание.
Ответы на нерекурсивные запросы реально зависят от запрашиваемого
сервера, но не зависят от индивидуальных особенностей запрашиваемой
стороны.)
5.2.1. Запрос : QNAME=SRI-NIC.ARPA, QTYPE=A
Формат этого запроса (и примерное содержание) представлен на рис.3.
ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й
Header (заголовок) OPCODE=SQUERY
Question (вопрос) QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A
Answer (ответ) <empty>
Authority (авторизация) <empty>
Additional (дополнение) <empty>
45
Рис.3. Формат сообщения/запроса QNAME=SRI-NIC.ARPA, QTYPE=A
Ответ на этот запрос (от сервера “C.ISI.EDU”) представлен на рис.4.
ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й
Header (заголовок) OPCODE=SQUERY, RESPONSE, AA
Question (вопрос) QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A
Answer (ответ)
SRI-NIC.ARPA. 86400 IN A 26.0.0.73
86400 IN A 10.0.0.51
Authority (авторизация) <empty>
Additional (дополнение) <empty>
Рис.4. Формат сообщения/ответа от авторизованного сервера “C.ISI.EDU” на запрос:
QNAME=SRI-NIC.ARPA, QTYPE=A
Заголовок ответа похож на заголовок запроса, за исключением
установленного в значение “1” бита “Response”, указывающий на то, что
данное сообщение является ответом, а не запросом. Кроме этого, отличие также
в том, что в заголовке ответа бит “Authoritative Answer” (“AA” —
авторизованный ответ) тоже имеет значение “1”, который указывает на то, что
данные (записи с IP-адресами), представленные в поле “Answer”, являются
авторизованными. Поля “Question” в обоих сообщениях (запрос и ответ)
совпадают.
Если точно такой же запрос (рис.3) был передан другому серверу,
который не был авторизован для зоны с сервером “SRI-NIC.ARPA”, то тогда
ответ будет иметь другой вид, который представлен на рис.5.
ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й
Header (заголовок) OPCODE=SQUERY, RESPONSE
Question (вопрос) QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A
Answer (ответ)
SRI-NIC.ARPA. 1777 IN A 10.0.0.51
1777 IN A 26.0.0.73
Authority (авторизация) <empty>
Additional (дополнение) <empty>
Рис.5. Формат сообщения/ответа от неавторизованного сервера на запрос:
QNAME=SRI-NIC.ARPA, QTYPE=A
Этот ответ отличается от предыдущего тем, что в нем, во-первых, бит
“АА” не установлен в ”1”, и, во-вторых, значение TTL — другое.
Предполагается, что данные не поступили зоны, но поступили из кэш-памяти.
46
И поэтому авторизованное значение TTL отличается от неавторизованного
значения TTL вследствие того, что последнего устарело при хранении в кэш-
памяти. Различие в порядке следования записей с IP-адресами в поле “Answer”
не является существенным.
ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й
Header (заголовок) OPCODE=SQUERY, RESPONSE, AA
Question (вопрос) QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*
Answer (ответ)
SRI-NIC.ARPA. 86400 IN A 26.0.0.73
86400 IN A 10.0.0.51
MX 0 SRI-NIC.ARPA.
HINFO DEC-2060 TOPS20
Authority (авторизация) <empty>
Additional (дополнение) <empty>
Рис.6. Формат сообщения/ответа от авторизованного сервера “C.ISI.EDU” на запрос:
QNAME=SRI-NIC.ARPA, QTYPE=*
ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й
Header (заголовок) OPCODE=SQUERY, RESPONSE
Question (вопрос) QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*
Answer (ответ)
SRI-NIC.ARPA. 12345 IN A 26.0.0.73
A 10.0.0.51
Authority (авторизация) <empty>
Additional (дополнение) <empty>
ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й
Header (заголовок) OPCODE=SQUERY, RESPONSE
Question (вопрос) QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*
Answer (ответ) SRI-NIC.ARPA. 1290 IN INFO DEC-2060 TOPS20
Authority (авторизация) <empty>
Additional (дополнение) <empty>
Рис.7. Форматы сообщений/ответов от двух неавторизованных серверов на запрос:
QNAME=SRI-NIC.ARPA, QTYPE=*
5.2.2. Запрос : QNAME=SRI-NIC.ARPA, QTYPE= *
Этот запрос совпадает с предыдущим запросом, за исключением
изменения в запрашиваемом типе имени QTYPE, в котором используется ЗСЗ
47
(“*”). В этом случае сервер “C.ISI.EDU” направит ответ, который представлен
на рис.6.
Если такой запрос был направлен на два сервера, которые не были
авторизованы для зоны с сервером “SRI-NIC.ARPA”, то тогда возможны два
ответа, которые представлены на рис.7.
Ни один из этих ответов (рис.7) не имеет бит “АА”, установленного в ”1”,
так как ни один ответ не содержит авторизованной информации. Разница в
содержании и различные значения TTL говорят о том, что два сервера
отправили информацию на хранение в кэш-память в разное время, и кроме
этого, первый сервер кэшировал ответ на запрос типа “QTYPE=A”, а второй
сервер — на запрос типа “HINFO”.
5.2.3. Запрос : QNAME=SRI-NIC.ARPA, QTYPE=MX
Этот тип запроса может быть применен почтовым сервером, который
пытается получить маршрутную информацию для соединения с другим
почтовым сервером с именем “HOSTMASTER@SRI-NIC.ARPA”. В этом случае
от сервера “C.ISI.EDU” поступит ответ, формат которого представлен на рис.8.
ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й
Header (заголовок) OPCODE=SQUERY, RESPONSE, АА
Question (вопрос) QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX
Answer (ответ) SRI-NIC.ARPA. 86400 IN MX 0 SRI-NIC.ARPA.
Authority (авторизация) <empty>
Additional (дополнение)
SRI-NIC.ARPA. 86400 IN A 26.0.0.73
A 10.0.0.51
Рис.8. Формат сообщения/ответа от авторизованного сервера “C.ISI.EDU” на запрос:
QNAME=SRI-NIC.ARPA, QTYPE=MX
В данном ответе в поле “Answer” содержится запись “МХ”. Кроме этого,
в поле “Additional” содержатся записи с сетевыми адресами, так как DNS-
сервер с именем “C.ISI.EDU” будет полагать, что запрашивающей стороне
необходим IP-адрес в целях корректной доставки информации,
транспортируемой почтовой службой.
5.2.4. Запрос: QNAME = SRI - NIC . ARPA , QTYPE = NS
DNS-сервер с именем “C.ISI.EDU” в ответ на этот запрос направит
сообщение, формат которого представлен рис.9.
Сообщение/запрос и сообщение/ответ отличаются между собой только
битами “АА” и “Response”, размещенных в заголовках. Сущность
48
сообщения/ответа (рис.9) заключается в следующем: сервер с этим именем
авторизован, такое имя существует, но отсутствуют записи о типе имени этого
сервера, которое представлено в поле “Answer”.
ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й
Header (заголовок) OPCODE=SQUERY, RESPONSE, AA
Question (вопрос) QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS
Answer (ответ) <empty>
Authority (авторизация) <empty>
Additional (дополнение) <empty>
Рис.9. Формат сообщения/ответа от авторизованного сервера “C.ISI.EDU” на запрос:
QNAME=SRI-NIC.ARPA, QTYPE=NS
5.2.5. Запрос : QNAME=SRI-NIC.ARPA, QTYPE=A
Если пользователь указал в запросе неправильное имя IP-узла, то тогда
DNS-сервер с именем “C.ISI.EDU” в ответ на этот запрос направит сообщение,
формат которого представлен рис.10.
ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й
Header (заголовок) OPCODE=SQUERY, RESPONSE, AA, RCODE=NE
Question (вопрос) QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A
Answer (ответ) <empty>
Authority (авторизация)
. SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.
870611 1800 300 604800 86400
Additional (дополнение) <empty>
Рис.10. Формат сообщения/ответа от авторизованного сервера “C.ISI.EDU”
на запрос (ошибочный): QNAME=SRI-NIC.ARPA, QTYPE=A
Этот ответ (рис.10) констатирует, что такое имя не существует. Эта
информация представлена с помощью специального символа “RCODE” (код
ответа) в поле “Header” (заголовок).
Запись “SOA” в поле “Authority” является дополнительной кэшируемой
информацией (отрицательной), которая позволяет DNS-клиенту использовать
этот ответ для указания, что в дальнейшем это имя не будет существовать в
течение времени, которое указано в поле “Minimum” записи “SOA” (в
рассматриваемом случае это время составляет 86400 сек).
5.2.6. Запрос : QNAME=BRL.MIL, QTYPE=A
49
Этот запрос будет передан на сервер с именем “C.ISI.EDU”, который в
ответ направит сообщение, формат которого представлен рис.11.
ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й
Header (заголовок) OPCODE=SQUERY, RESPONSE
Question (вопрос) QNAME=BRL.MIL, QCLASS=IN, QTYPE=A
Answer (ответ) <empty>
Authority (авторизация)
MIL. 86400 IN NS SRI-NIC.ARPA.
86400 NS A.ISI.EDU.
Additional (дополнение)
A.ISI.EDU. A 26.3.0.103
SRI-NIC.ARPA. A 26.0.0.73
A 10.0.0.51
Рис.11. Формат сообщения/ответа от авторизованного сервера “C.ISI.EDU” на запрос:
QNAME=BRL.MIL, QTYPE=A
Этот ответ содержит пустое поле “Answer”, но это сообщение не является
авторизованным, так как оно является указателем направления. DNS-сервер с
именем “C.ISI.EDU”, “понимающий”, что он не является авторизованным
сервером для сегмента “MIL”, указывает запрашивающей стороне на серверы
“A.ISI.EDU” и “SRI-NIC.ARPA”, чтобы она обратилась к последним, так как
они являются авторизованными для этого сегмента “MIL”.
5.2.7. Запрос : QNAME=USC-ISIC.ARPA, QTYPE=A
Этот запрос будет передан на сервер с именем “A.ISI.EDU”, который в
ответ направит сообщение, формат которого представлен рис.12.
ПОЛЯ СООБЩЕНИЯ С О Д Е Р Ж А Н И Е П О Л Е Й
Header (заголовок) OPCODE=SQUERY, RESPONSE, AA
Question (вопрос) QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A
Answer (ответ)
USC-ISIC.ARPA. 86400 IN CNAME C.ISI.EDU.
C.ISI.EDU. 86400 IN A 10.0.0.52
Authority (авторизация) <empty>
Additional (дополнение) <empty>
Рис.12. Формат сообщения/ответа от авторизованного сервера “A.ISI.EDU” на запрос:
QNAME=USC-ISIC.ARPA, QTYPE=A
В данном ответе (рис.12) установленный в “1” бит “АА” заголовка
гарантирует, что данные, которые сравнивались относительно записи QNAME,
являются авторизованными, но это еще не означает, что эти данные являются
50