Компьютерные сети. 6-е изд. - Эндрю Таненбаум
Шрифт:
Интервал:
Закладка:
Обычно оконечный распознаватель направляет запрос рекурсивного поиска локальному распознавателю, то есть он просто выдает запрос и ожидает ответа. Локальный распознаватель, в свою очередь, направляет ряд запросов соответствующим серверам имен для каждого элемента именной иерархии. Сервер имен, отвечающий за определенную часть этой иерархии, при этом считается авторитетным сервером имен (authoritative name server) для этого домена. Как мы увидим позже, система DNS использует кэширование, но кэш при этом может устаревать. Авторитетный сервер имен обладает, как понятно из названия, непререкаемым авторитетом. Он по определению всегда прав. Перед тем как переходить к более детальному рассмотрению работы DNS, давайте немного поговорим об иерархии серверов имен DNS и процессе выделения имен.
Получив запрос от оконечного распознавателя хоста, локальный распознаватель осуществляет процесс разрешения имен, пока не найдет нужный ответ (или не найдет его вовсе). Он не возвращает частичные ответы. С другой стороны, корневой сервер имен (и каждый последующий) не отправляет запрос локальному серверу имен рекурсивно. Он возвращает частичный ответ и переходит к следующему запросу. Локальный распознаватель обеспечивает продолжение процесса разрешения имен путем выдачи дальнейших итеративных запросов.
В ходе процесса разрешения имен обычно используются оба механизма. Рекурсивные запросы практически всегда кажутся предпочтительными, но многие серверы имен (особенно корневые) их не обрабатывают. Они слишком загружены. Итеративные запросы перекладывают ответственность на их источник. Для локального сервера имен разумно поддерживать рекурсивные запросы, чтобы предоставлять сервис хостам на своем домене. Эти хосты не обязательно должны быть сконфигурированы для запуска полного сервера имен, достаточно возможности обращения к локальному серверу. Каждый запрос содержит 16-битный идентификатор транзакции; он копируется в ответ, и, таким образом, сервер имен может выдавать необходимые ответы, даже когда поступает много запросов одновременно.
Все ответы, в том числе все возвращенные частичные ответы, хранятся в кэше. Так, если компьютер, расположенный в домене cs.vu.nl, запросит имя cs.uchicago.edu, ответ будет сохранен в кэше. Если вскоре после этого другой хост в домене cs.vu.nl тоже запросит имя cs.uchicago.edu, ответ уже будет известен. Более того, если хост запрашивает другой хост в том же домене, например noise.cs.uchicago.edu, запрос может быть направлен напрямую на авторитетный сервер имен для домена cs.uchicago.edu. Сходным образом, при запросе других доменов по адресу uchicago.edu запрос может быть передан напрямую серверу имен домена uchicago.edu. Использование ответов, сохраненных в кэше, серьезно сокращает количество шагов в запросе и повышает производительность. Такой сценарий на самом деле является худшим из возможных вариантов, так как в кэше нет полезной информации.
Кэшированные ответы не являются авторитетными, так как изменения в домене cs.uchicago.edu не распространяются автоматически на все кэши по всему миру, хранящие информацию об этом домене. В силу этого время жизни записей кэша не должно быть слишком большим. Именно поэтому каждый элемент базы данных DNS, о которой мы поговорим чуть позже, называемый записью ресурсов DNS, содержит поле Time_to_live. Оно сообщает удаленным серверам имен, как долго хранить эту запись в кэше. Если какой-либо компьютер обладает постоянным IP-адресом в течение многих лет, такую информацию можно хранить в кэше в течение суток. В случае более изменчивой информации запись безопаснее удалить спустя несколько секунд или одну минуту.
DNS-запросы имеют простой формат, который содержит разную информацию, включая запрашиваемое имя (QNAME), и вспомогательные сведения, такие как идентификатор транзакции (он часто используется для сопоставления запросов с ответами). Изначально этот идентификатор состоял только из 16 бит, а запросы и ответы были незащищенными. Такой подход делал систему DNS уязвимой для различных видов атак, в том числе так называемого отравления кэша, о котором мы подробно поговорим в главе 8. При выполнении ряда итеративных операций поиска рекурсивный DNS-распознаватель может отправить все содержимое поля QNAME ряду авторитетных серверов имен, возвращающих ответы. В какой-то момент разработчики протокола заметили, что отправка всего содержимого поля QNAME каждому авторитетному серверу среди итеративных распознавателей была небезопасной. Теперь многие рекурсивные распознаватели используют QNAME-минимизацию, при которой локальный распознаватель отправляет ту часть запроса, которую способен обработать соответствующий авторитетный сервер имен. Например, при разрешении с помощью QNAME-минимизации имени www.cs.uchicago.edu локальный распознаватель отправит авторитетному серверу для домена uchicago.edu только строку cs.uchicago.edu, а не полностью квалифицированное доменное имя (FQDN), чтобы избежать его раскрытия для авторитетного сервера. Более подробную информацию о QNAME-минимизации вы найдете в RFC 7816.
До недавнего времени в качестве транспортного протокола DNS-запросы и DNS-ответы использовали UDP, исходя из тех соображений, что такие запросы и ответы должны быть быстрыми и легковесными и не могут позволить себе накладные расходы «тройного рукопожатия» в TCP. Но после выявления недостаточной безопасности протокола DNS, что сопровождалось множеством попыток использовать его уязвимость (начиная с атак отравления кэша и заканчивая DDoS-атаками), отмечается растущая тенденция к использованию TCP в качестве транспортного протокола для DNS. Со временем это позволило системе DNS эффективно применять современные безопасные протоколы транспортного и прикладного уровней, такие как DNS поверх TLS (DNS-over-TLS, DoT) и DNS поверх HTTPS (DNS-over-HTTPS, DoH). Мы подробно коснемся этих моментов далее.
Если оконечный DNS-распознаватель не получает ответа в течение сравнительно короткого периода времени (периода ожидания), DNS-клиент направляет этот запрос к другому серверу домена после нескольких повторных попыток. Эта возможность предусмотрена на случай, если сервер выйдет из строя или будет потерян ответный пакет.
7.1.3. Пространство имен и иерархия DNS
Управление большим и постоянно меняющимся набором имен — нетривиальная задача. На обычных письмах требуется, так или иначе, указывать страну, регион, город, улицу, номер дома, квартиру и фамилию получателя. Благодаря использованию такой иерархической схемы не возникает путаницы между Марвином Андерсоном, живущим на Мейн-стрит в Уайт-Плейнс, штат Нью-Йорк, и Марвином Андерсоном с Мейн-стрит в Остине, штат Техас. Система DNS работает аналогично.
Основа иерархии доменных имен разработана Корпорацией по управлению доменными именами и IP-адресами (ICANN). Она была создана именно для этих целей в 1998 году, поскольку интернет превратился в мировою экономическую среду. Весь интернет разделен на более чем 250 доменов верхнего уровня (top-level domains), каждый из которых охватывает множество хостов. Все домены делятся на поддомены, которые тоже разделены на поддомены, и т.д. Все эти домены составляют иерархию пространства имен, которую можно представить в виде дерева (илл. 7.1). Его листьями являются домены, которые не имеют поддоменов (но, безусловно, содержат хосты). Конечный домен может состоять из одного хоста или представлять компанию и содержать в себе тысячи хостов.
Илл. 7.1. Часть доменного пространства
