С каким протоколом работает DNS

Обновлено: 01.07.2024

Если вы когда-нибудь задумывались, откуда взялся DNS, у вас есть шанс это выяснить! Краткий обзор истории DNS также поможет вам понять, почему DNS-серверы работают в основном в системах типа Linux и Unix. Затем мы увидим уровни модели OSI, на которых работает DNS, и ближе к концу страницы вы узнаете, как домены (и DNS-серверы) структурированы в Интернете для обеспечения бесперебойной работы и эффективности.

История

DNS зародился в первые дни, когда Интернет был лишь небольшой сетью, созданной Министерством обороны для исследовательских целей. Имена хостов (простые имена компьютеров) компьютеров вводились вручную в файл (называемый HOSTS), который находился на центральном сервере. Каждый сайт/компьютер, которому нужно было разрешать имена хостов, должен был загрузить этот файл. Но по мере роста числа хостов рос и файл HOSTS (Linux, Unix, Windows и NetWare все еще используют такие файлы), пока он не стал слишком большим для загрузки компьютерами и генерировал огромное количество трафика! Так они думали. Заткнись.. давай найдем лучшее решение. а в 1984 году была введена система доменных имен.

Протокол

Система доменных имен — это «иерархически распределенная база данных», что является причудливым способом сказать, что ее слои расположены в определенном порядке и что ее данные распределены по широкому кругу машин (точно так же, как корни ветви дерева от главного корня).

Сегодня у большинства компаний есть собственный небольшой DNS-сервер, чтобы компьютеры могли без проблем находить друг друга. Если вы используете Windows 2000 и Active Directory, то наверняка используете DNS для разрешения имен ваших компьютеров. Microsoft создала собственную версию DNS-сервера, называемого WINS-сервером, что означает Windows Internet Name Service, но это старая технология, использующая протоколы, которые далеко не так эффективны, как DNS, поэтому для Microsoft было естественным отойди от WINS и отойди в сторону DNS, ведь весь интернет работает на DNS :)

Протокол DNS работает, когда ваш компьютер отправляет DNS-запрос на сервер имен для разрешения домена. Например, вы вводите «www.firewall.cx» в своем веб-браузере, это запускает DNS-запрос, который ваш компьютер отправляет на DNS-сервер, чтобы получить IP-адрес веб-сайта! На последующих страницах есть подробный пример, поэтому я пока не буду вдаваться в подробности.

Протокол DNS обычно использует протокол UDP в качестве транспортного средства из-за его небольших накладных расходов по сравнению с TCP; чем меньше накладных расходов у протокола, тем он быстрее!

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

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

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

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

Далее мы подробно рассмотрим структуру интернет-доменов и DNS-серверов, чтобы убедиться, что модель работает безупречно и эффективно!

Иерархия серверов доменных имен в Интернете

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

Ну, это не тот случай. Структура DNS спроектирована таким образом, что DNS-серверу не нужно знать обо всех возможных доменах, а только о тех, которые находятся непосредственно над ним и под ним.

Давайте объясним, как это работает:

Каждый домен, включая те, о которых мы говорим (cisco, firewall, microsoft), имеет то, что мы называем «первичным DNS» и «вторичным DNS». Первичный DNS — это тот, который содержит всю информацию о своем домене. Вторичный сервер выступает в качестве резервного на случай сбоя основного DNS. Процесс, в котором первичный DNS-сервер отправляет свою копию на вторичный DNS-сервер, называется Передача зоны и рассматривается в разделе База данных DNS.

Итак, возникает вопрос на миллион долларов: как вы создаете поддомены и www (известные как ресурсные записи)?

Ответ довольно прост:

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

Эти изменения затем медленно распространяются на авторитетные DNS-серверы, которые отвечают за зону вашего домена, и тогда весь Интернет будет связываться с этими DNS-серверами, когда им потребуется доступ к любой части вашего домена.< /p>

Протокол Domain Network System (DNS) помогает пользователям Интернета и сетевым устройствам находить веб-сайты, используя удобочитаемые имена хостов вместо числовых IP-адресов.

Упрощенный процесс DNS работает следующим образом:

История DNS

Идея сопоставлять удобочитаемые имена хостов с числовыми адресами возникла в 1970-х годах, когда появилась сеть ARPANET, предшественница современного Интернета. Стэнфордский исследовательский институт (SRI) отвечал за ведение текстового файла hosts.txt, в котором имена хостов сопоставлялись с адресами компьютеров в сети ARPANET. Чтобы добавить запись в файл hosts, пользователи звонили сотрудникам SRI в рабочее время и вручную добавляли хост и связанный с ним числовой адрес в файл.

В 1980-х годах было понятно, что централизованный файл хоста, обновляемый вручную, не является масштабируемым подходом. Джон Постел из Университета Южной Калифорнии, чья команда отвечала за список присвоенных номеров ARPANET, поручил Полу Мокапетрису создать автоматизированную систему именования. Мокапетрис должен был найти компромисс между пятью конкурирующими техническими решениями, но вместо этого он создал собственное решение — систему доменных имен.

В 1984 году четверо студентов Калифорнийского университета в Беркли написали первую реализацию DNS-сервера имен для Unix и назвали ее BIND. В 1990-х BIND был перенесен на Windows NT. На сегодняшний день это наиболее широко используемое программное обеспечение DNS в мире.

В 1987 году DNS был формализован в RFC 1035.

Спецификация протокола DNS

Пространство доменных имен

Пространство имен DNS управляет общедоступными именами хостов, используемыми в Интернете. Пространство имен представляет собой древовидную структуру, в которой каждый узел дерева имеет текстовую метку и ноль или более записей ресурсов DNS (RR), описывающих домен.

Синтаксис и формат доменного имени

Доменное имя состоит из одной или нескольких частей, называемых метками, которые разделены точками. Метка может содержать до 63 символов. Крайняя правая метка — это домен верхнего уровня (TLD), а следующие справа налево метки находятся ниже в иерархии пространств имен. Каждая метка известна как поддомен метки над ней. DNS поддерживает до 127 иерархических уровней.

Архитектура преобразователя DNS и сервера имен

Существует два ключевых компонента, которые разрешают DNS-запросы клиентов: преобразователь DNS и сервер DNS-имен.

Резолвер DNS

Этот сервер, также называемый рекурсивным преобразователем, предназначен для приема DNS-запросов от веб-браузеров и других приложений или сетевых устройств. Он получает имя хоста и отвечает за отслеживание IP-адреса для этого имени хоста:

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

Авторитетный сервер имен

Авторитетный сервер имен является последней остановкой в DNS-запросе. Он содержит основной файл DNS для управляемой им зоны DNS, который содержит доверенные и правильные записи ресурсов для всех доменов в зоне.

Формат DNS-сообщения

DNS-связь осуществляется с помощью двух типов сообщений: запросов и ответов. Как формат запроса DNS, так и формат ответа состоят из следующих разделов:

Раздел заголовка содержит идентификацию; Флаги; Количество вопросов; количество ответов; Количество записей авторитетных ресурсов (RR); и Количество дополнительных записей ресурсов.
Поле флага содержит разделы из одного или четырех битов, указывающие тип сообщения, является ли сервер имен полномочным; является ли запрос рекурсивным или нет, был ли запрос усечен и статус.
Раздел вопросов содержит доменное имя и тип разрешаемой записи (A, AAAA, MX, TXT и т. д.). Каждая метка в доменном имени имеет префикс своей длины.
В разделе ответов есть записи ресурсов запрашиваемого имени.

Транспортный протокол DNS

DNS использует протокол пользовательских дейтаграмм (UDP) на порту 53 для обслуживания запросов DNS. UDP предпочтительнее, потому что он быстрый и имеет низкие накладные расходы. DNS-запрос — это один UDP-запрос от DNS-клиента, за которым следует один UDP-ответ от сервера.

Если ответ DNS превышает 512 байт или если DNS-сервер управляет такими задачами, как передача зоны (перенос записей DNS с основного на дополнительный DNS-сервер), вместо UDP используется протокол управления передачей (TCP). включить проверку целостности данных.

Главные файлы DNS (файлы зон)

Главный файл DNS — это текстовый файл, хранящийся на сервере имен DNS, который определяет информацию DNS для отдельной зоны DNS. Файл содержит следующие данные:

Глобальное время жизни (TTL) — как долго записи должны храниться в локальном кэше DNS.
Запись начала полномочий (SOA) — основной полномочный сервер имен для зоны.
Одна или несколько записей ресурсов — подробнее см. ниже.

Записи ресурсов DNS

Записи ресурсов используются для хранения имен хостов, IP-адресов и другой информации на серверах имен DNS. Запись состоит из следующих полей:

Имя — это буквенно-цифровой идентификатор записи DNS.
TTL (время жизни) указывает, как долго запись должна храниться в локальном кеше.
Класс Record указывает пространство имен — обычно IN, пространство имен Интернета.
Тип записи – это тип записи DNS, например A, CNAME, MX.
Данные записи содержат значения DNS, например IP-адрес для имени хоста.

Наиболее распространенные типы записей DNS, поддерживаемые протоколом DNS:

Записи DNS-сервера (NS) — указывает авторитетный сервер имен для зоны DNS.
Записи сопоставления адресов IPv4 (A) — имя хоста и его IPv4-адрес
Записи IPv6-адресов (AAAA) — имя хоста и его IPv6-адрес
Записи канонических имен (CNAME) — связывают имя хоста с псевдонимом.
Запись Mail eXchanger (MX) — указывает почтовый сервер SMTP для домена.

DNS следующего поколения

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

- динамический выбор одной из нескольких CDN для предоставления каждому пользователю оптимальной работы - интеллектуальная маршрутизация соединений между центрами обработки данных, распределенными по всему миру - маршрутизация пользователей к физически ближайшему сетевому ресурсу - интеграция между локальными центрами обработки данных и облаком и копирование или синхронизация данных в больших масштабах — интеллектуальная маршрутизация трафика с использованием информации о готовности ресурсов, нагрузке и состоянии сети для значительного повышения производительности

Эти возможности стали возможными благодаря управляемым DNS-серверам нового поколения, способным интеллектуально маршрутизировать и фильтровать трафик. Узнайте больше об интеллектуальной платформе DNS NS1 и выведите DNS на новый уровень.

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

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

В наборе протоколов TCP/IP DNS является протоколом прикладного уровня. Протокол DNS по умолчанию использует протокол пользовательских дейтаграмм (UDP), но может также работать по протоколу управления передачей (TCP) в качестве резервного варианта, когда брандмауэры блокируют UDP.

И UDP, и TCP являются протоколами транспортного уровня. UDP — это облегченный протокол, который не требует рукопожатия для установления соединения или подтверждения доставки, тем самым сокращая количество необходимых пакетов, затраченное время и круговые поездки. Самый большой недостаток UDP заключается в том, что нет никаких гарантий, что пакет был получен другой стороной, поэтому приложение должно обрабатывать случаи, когда ответ не получен.

С другой стороны, TCP требует установления соединения через трехэтапное рукопожатие и имеет проверку ошибок доставки, но требует больше циклов и, следовательно, больше времени.

Поскольку мы рассматриваем протоколы TCP/IP, в некоторых областях мы перейдем к разрядности. Но не пугайтесь — вам не нужно учиться обращаться с «битовыми флагами», чтобы понимать DNS. В Catchpoint мы используем — и настоятельно рекомендуем — программу захвата пакетов, такую как Wireshark, чтобы сделать пакеты понятными для человека и упростить отладку.

Протокол

< /p>

Протокол DNS состоит из трех типов сообщений: запросов, ответов и обновлений. Мы не будем освещать «обновления» в нашей серии, поскольку они не влияют на работу конечного пользователя. Сообщение DNS может состоять из пяти разделов: Заголовок DNS, Вопрос, Ресурсные записи ответа, Ресурсные записи авторитетных источников и Дополнительные ресурсные записи.

Заголовок

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

Следующее поле предназначено для флагов. Это, вероятно, самая важная часть пакета DNS, поскольку эти флаги отличают ответ от запроса и итеративный запрос от рекурсивного. Они перечислены в следующем порядке:

Бит 1: QR, флаг запроса/ответа. Когда 0, сообщение является запросом. Когда 1, сообщение является ответом.
Биты 2–5: код операции, код операции. Сообщает принимающей машине цель сообщения. Обычно 0 означает обычный запрос, однако есть и другие допустимые значения, например 1 для обратного запроса и 2 для состояния сервера.
Бит 6: AA, авторитетный ответ. Устанавливайте только в том случае, если отвечающая машина является полномочным сервером имен запрашиваемого домена.
Бит 7: ТС, усеченный. Установите, если пакет больше максимального размера UDP, равного 512 байтам.
Бит 8: RD, требуется рекурсия. Если 0, запрос является итеративным запросом. Если 1, запрос рекурсивный. Дополнительную информацию см. в нашем посте о рекурсии.
Бит 9: RA, доступна рекурсия. Устанавливается при ответе, если сервер поддерживает рекурсию.
Бит 10: Z. Зарезервирован для будущего использования, должен быть установлен на 0 во всех запросах и ответах.
Бит 11: AD, достоверные данные. Используется в DNSSEC. Считается частью Z на старых машинах.
Бит 12: CD, проверка отключена. Используется в DNSSEC. Считается частью Z на старых машинах.
Биты 13–16: Rcode, код возврата. Обычно он равен 0, если ошибки нет, или 3, если имя не существует.

Остальные четыре поля заголовка — это количество вопросов, записей ресурсов ответов, записей ресурсов полномочий и дополнительных записей ресурсов. Эти цифры различаются в зависимости от того, является ли это запросом или ответом, и каким типом ответа. Однако в целом всегда будет как минимум один вопрос.

Вопрос

Вопрос присутствует как в запросе, так и в ответе, и должен быть идентичным. Некоторые инструменты, такие как Wireshark, называют его «Запрос» (см. изображение выше).

A, IPv4-адрес: с которым сопоставляется доменное имя. В каждом домене веб-сайта должна быть хотя бы одна запись A, иначе ваши конечные пользователи не смогут получить доступ к вашему веб-сайту.
Запись адреса AAAA, Quad-A, IPv6. Адрес IPv6 — это тип, которому соответствует доменное имя. Поскольку IPv4-адреса больше не доступны, существует большое движение в поддержку IPv6, однако пока не все интернет-провайдеры и веб-сайты поддерживают его.
MX, запись Mail eXchange: указывает, какой почтовый сервер принимает сообщения электронной почты от имени получателя домена.
NS, запись сервера имен: сопоставляет домен с его авторитетным сервером имен. В каждом домене должно быть более одной записи NS.

Ответить на ресурсные записи

< бр />

Ответ состоит из записей ресурсов, которые отвечают на вопрос. Раздел «Ответ» присутствует в ответе рекурсивного распознавателя на компьютер конечного пользователя или в ответе полномочного сервера имен домена на рекурсивный распознаватель. Это зависит от типа вопроса, но для DNS-разрешения веб-доменов это будет A, AAAA или CNAME. CNAME расшифровывается как Canonical Name, это означает, что домен в запросе является псевдонимом для другого домена.

Первые три поля в записи ресурса идентичны формату вопроса и представляют собой имя RR, тип RR и класс RR. Однако записи RR содержат три дополнительных поля: двухбайтовое значение времени жизни, однобайтовое поле длины данных и поле данных. Содержимое полей данных зависит от типа записи, но вот основные из них:

A: одно поле данных, хранящее четырехбайтный IPv4-адрес
AAAA: одно поле данных, хранящее шестнадцатибайтовый IPv6-адрес
MX: два поля данных, в одном из которых хранится значение приоритета, а в другом — IP-адрес.
NS: одно поле данных, в котором хранится доменное имя авторитетного сервера имен.
CNAME: одно поле данных, в котором хранится имя домена, псевдонимом которого является домен вопроса.

Записи авторитетных ресурсов

< бр />

Дополнительные записи

< бр />

Дополнительные или «связывающие» записи помогают избежать дополнительной рекурсии, предоставляя IP-адреса (записи A или AAAA) записей NS, отправленных в полномочном разделе или разделе ответов, поэтому эти домены не нужно разрешать. Эти RR обычно представляют собой записи A и/или AAAA для записей NS в разделе полномочий, хотя они могут быть любой записью.

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

Ответ: DNS в основном использует UDP-порт 53, но со временем DNS будет все больше полагаться на TCP-порт 53. DNS всегда проектировался для использования как UDP, так и TCP-порта 53 с самого начала 1 , при этом UDP используется по умолчанию, и возвращается к использованию TCP, когда он не может обмениваться данными по UDP, как правило, когда размер пакета слишком велик для проталкивания. в одном пакете UDP.

Когда DNS переключается на TCP?

Следующий естественный вопрос: когда размер сообщений DNS превысит 512 байт? На самом деле, это происходит довольно часто в сегодняшних условиях. Когда DNS был впервые реализован, единственное, что могло быть настолько большим, что превышало ограничение в 512 байт, — это передача зоны, при которой один DNS-сервер отправляет каждую отдельную запись ресурса в зоне на другой компьютер, обычно на другой DNS-сервер.< /p>

Или тот же запрос может возвращать следующие записи TXT, каждая из которых обеспечивает определенную функцию, например обнаружение спама или проверку сайта, как показано на рисунке FAQ-6:

Если зона подписана DNSSEC, она будет регулярно возвращать большие ответы из-за криптографических ключей и подписей, как показано на рисунке FAQ-7:

Поскольку все больше и больше людей внедряют новые функции, такие как IPv6, предотвращение спама и DNSSEC, DNS с большей вероятностью переключится на TCP из-за большего размера ответа.

Что произойдет, если TCP заблокирован?

В любом случае, когда размер сообщения превышает 512 байт, это приведет к установке бита «TC» (усечение) в DNS, информируя клиента о том, что длина сообщения превысила допустимый размер. В таких ситуациях клиенту необходимо выполнить повторную передачу по протоколу TCP, размер которого не ограничен. Если DNS-серверы и сетевое окружение не могут поддерживать большие пакеты UDP, это вызовет повторную передачу через TCP; если TCP заблокирован, большой ответ UDP приведет либо к фрагментации IP, либо к полному отбрасыванию. Конечным признаком для конечного клиента обычно является медленное разрешение DNS или невозможность разрешения определенных доменных имен вообще.

Размер имеет значение: EDNS

Возможно, вам интересно, откуда взялось ограничение размера в 512 байт. Размер полезной нагрузки UDP в 512 байт зависит от IPv4. Стандарт IPv4 2 указывает, что каждый хост должен иметь возможность собирать пакеты размером 576 байт или меньше, удалять заголовок и другие параметры, оставляя 512 байтов для данных полезной нагрузки. Именно по этой причине изначально существует ровно 13 корневых серверов DNS 3: 13 доменных имен и 13 адресов IPv4 прекрасно укладываются в один UDP-пакет.

Это ограничение размера уже давно признано проблемой. В 1999 году был предложен Механизм расширения для DNS (EDNS), который с годами обновлялся, увеличивая размер до 4096 байт или 4 килобайт. Таким образом, если вы используете относительно современный DNS-сервер, шансы на его переключение на TCP должны быть небольшими (меньше).

Однако, несмотря на то, что EDNS существует уже давно, его поддержка не была такой универсальной, как должна была бы быть 4 . Некоторое сетевое оборудование, такое как брандмауэры, может по-прежнему делать предположения о размере пакета DNS. Брандмауэр может отбросить или отклонить большой DNS-пакет, думая, что это атака. Это поведение, возможно, не вызывало видимых проблем в прошлом (или вызывало, но никто не понимал почему), но поскольку размер данных DNS продолжает увеличиваться, важно, чтобы все сетевое оборудование было правильно настроено для поддержки больших размеров пакетов DNS. Если сетевая среда не полностью поддерживает большие DNS-сообщения, это может привести к тому, что DNS-сообщение будет отклонено сетевым оборудованием или частично отброшено во время фрагментации.Для конечного пользователя это выглядит так: DNS-запросы остаются без ответа или выполняются очень долго, создавая впечатление, что «DNS/сеть работают очень медленно».

Несмотря на то, что EDNS необходим для работы современных DNS, возможность отправки сообщений большего размера способствовала объемным атакам, таким как Amplification и Reflection.

1 RFC 1034, написанный в 1987 году, определяет использование TCP для DNS в качестве требования.

2 RFC 791, опубликованный в 1981 году

3 Несмотря на то, что сегодня для корневого DNS-сервера существует всего 13 IPv4-адресов, на самом деле он распределен по многим узлам по всему миру с использованием таких методов, как произвольная рассылка и балансировка нагрузки.

4 Осознавая эту проблему, сообщество DNS провело мероприятие «День флага DNS» 1 февраля 2019 года, объявив его днем, когда EDNS должна полностью поддерживаться в будущем.

Читайте также: