SRV представляют собой более новый тип записей, позволяющий идентифицировать хост как определенный сервис в рамках домена. Например, веб-сервер для домена www.cs.uchicago.edu может быть идентифицирован как hnd.cs.uchicago.edu. Данный тип записей является обобщением записей типа MX, которые выполняют ту же задачу, но только для почтовых серверов.
Записи SPF позволяют домену закодировать информацию о том, какие компьютеры в рамках домена будут отправлять письма в остальную часть интернета. Это помогает принимающим устройствам отсеивать недопустимую почту. Если почта поступает от компьютера с именем dodgy, в то время как согласно записям домена почта должна поступать только от компьютера с именем smtp, велика вероятность того, что данные сообщения являются спамом.
Последний в списке тип записей, TXT, изначально предназначался для того, чтобы позволить доменам идентифицировать себя произвольным образом. Сегодня эти записи обычно используются для кодирования машиночитаемой информации; обычно это SPF-информация.
Наконец, рассмотрим последнее поле записи ресурсов — Value (Значение). Оно может содержать число, имя домена или текстовую ASCII-строку — это зависит от типа записи. Краткое описание полей Value для каждого из основных типов записей дано на илл. 7.4.
Записи DNSSEC
В ходе изначального внедрения DNS безопасность этого протокола не учитывалась. В частности, серверы имен и распознаватели DNS могли манипулировать содержимым любой DNS-записи, в результате чего клиент мог получать некорректную информацию. В спецификации RFC 3833 описаны некоторые проблемы безопасности DNS, а также их решение с помощью записей DNSSEC. Записи DNSSEC позволяют включать в ответы серверов имен DNS цифровую подпись, которую впоследствии может проверить распознаватель (локальный или оконечный), чтобы убедиться в том, что DNS-запись не подвергалась изменениям или искажениям. Каждый DNS-сервер вычисляет хеш (своего рода длинную контрольную сумму) набора записей ресурсов (Resource Record Set, RRSET) для каждого набора записей ресурсов одного типа, используя свои закрытые криптографические ключи. Соответствующие открытые ключи можно использовать для проверки подписей наборов RRSET. (Если вы не знакомы с шифрованием, в главе 8 будет предоставлена более подробная техническая информация.)
Прежде чем проверять подпись набора RRSET с помощью соответствующего открытого ключа сервера имен, естественно, нужно убедиться в подлинности самого ключа. Это можно сделать, если открытый ключ авторитетного сервера имен подписан родительским сервером в иерархии имени. Например, авторитетный сервер имен домена .edu может подписывать открытый ключ, привязанный к авторитетному серверу имен домена uchicago.edu, и т.д.
Технология DNSSEC подразумевает наличие двух записей ресурсов, привязанных к открытым ключам: RRSIG и DNSKEY. Запись RRSIG ассоциируется с подписью набора RRSET, который подписывается соответствующим закрытым ключом авторитетного сервера имен. Запись DNSKEY представляет собой открытый ключ для соответствующего набора RRSET, подписываемого закрытым ключом родителя. Такая иерархическая структура подписей делает возможным групповое распространение открытых ключей DNSSEC для иерархии серверов имен. Отдельно требуется распространять только открытые ключи корневого уровня, и они могут распространяться так же, как распознаватели получают информацию об IP-адресах корневых серверов имен. В главе 8 мы подробнее остановимся на технологии DNSSEC.
DNS-зоны
На илл. 7.5 показано, какую информацию может содержать типичная запись ресурсов DNS для определенного доменного имени. Здесь представлена часть базы данных (гипотетической) для домена cs.vu.nl (см. илл. 7.1), которую часто называют файлом DNS-зоны (DNS zone file), или просто DNS-зоной (DNS zone). Данный файл зоны содержит семь типов записей ресурсов.
Первая незакомментированная строка листинга на илл. 7.5 содержит базовую информацию о домене, которая для нас не важна. Далее две строки указывают на два хоста, на которые нужно попытаться доставить электронную почту для person@cs.vu.nl. Сначала следует связаться с хостом zephyr. В случае неудачи следует попробовать доставить письмо хосту top. Следующая строка задает в качестве сервера имен домена хост star.
После пустой строки, добавленной для удобства чтения, следуют строки, сообщающие IP-адреса хостов star, zephyr и top. Затем следует псевдоним www.cs.vu.nl, позволяющий не обращаться к какому-то конкретному компьютеру. Создание этого псевдонима позволяет домену cs.vu.nl изменять свой веб-сервер, не меняя адрес, по которому люди к нему обращаются. С той же целью в следующей строке создается псевдоним ftp.cs.vu.nl для FTP-сервера.
; Authoritative data for cs.vu.nl
cs.vu.nl. 86400 IN SOA star boss (9527,7200,7200,241920,86400)
cs.vu.nl. 86400 IN MX 1 zephyr
cs.vu.nl. 86400 IN MX 2 top
cs.vu.nl. 86400 IN NS star
star 86400 IN A 130.37.56.205
zephyr 86400 IN A 130.37.20.10
top 86400 IN A 130.37.20.11
www 86400 IN CNAME star.cs.vu.nl
ftp 86400 IN CNAME zephyr.cs.vu.nl
flits 86400 IN A 130.37.16.112
flits 86400 IN A 192.31.231.165
flits 86400 IN MX 1 flits
flits 86400 IN MX 2 zephyr
flits 86400 IN MX 3 top
rowboat IN A 130.37.56.201
IN MX 1 rowboat
IN MX 2 zephyr
little-sister IN A 130.37.62.23
laserjet IN A 192.31.231.216
Илл. 7.5. Часть гипотетической базы данных DNS (файла зоны) домена cs.vu.nl
В секции, относящейся к хосту flits, указаны два IP-адреса и три возможных варианта адреса для обработки почты, направляемой на адрес flits.cs.vu.nl. Разумеется, прежде всего нужно попробовать доставить письмо самому хосту flits. Но если он выключен, необходимо обратиться к хостам zephyr и top.
Следующие три строки содержат типичные записи для компьютера, в данном случае для rowboat.cs.vu.nl. Эти строки содержат его IP-адрес, а также имена первого и второго хостов для доставки почты. Следом идет запись о компьютере, неспособном самостоятельно получать почту. Последняя строка, вероятно, описывает подключенный к интернету лазерный принтер.
Теоретически один сервер мог бы содержать всю базу данных DNS и отвечать на все запросы к ней. На практике он оказался бы настолько перегружен, что был бы бесполезен. Более того, если бы он когда-нибудь отключился, то весь интернет перестал бы работать.
Чтобы избежать проблем, связанных с хранением всей информации в одном месте, пространство имен DNS разделено на непересекающиеся зоны. На илл. 7.6 показан один из способов разделения пространства имен с илл. 7.1. Здесь каждая очерченная зона содержит некоторую часть общего дерева доменов.
Расстановка границ внутри каждой зоны определяется ее администратором. Это решение зависит от того, сколько серверов имен требуется в той или иной зоне. Например, у Чикагского университета (илл. 7.6) есть зона для домена uchicago.edu, которая управляет доменом cs.uchicago.edu, но не доменом eng.uchicago.edu, расположенным в отдельной зоне со своими серверами имен. Подобное решение может быть принято, когда факультет английского языка не хочет управлять собственным сервером имен, но этого хочет факультет вычислительной техники.
Илл. 7.6. Часть пространства имен DNS, разделенная на зоны (они обведены)
7.1.5. Разрешение имен
Каждая зона ассоциируется с одним или несколькими серверами имен. Это хосты, на которых находится база данных для зоны. Обычно у зоны есть один основной сервер имен, который берет информацию из файла на своем диске, и один или несколько второстепенных серверов, получающих данные с основного сервера. Для повышения надежности некоторые серверы имен могут быть расположены вне зоны.