Структура DNS пакета / Habr
Решил как то написать снифер DNS, так сказать just for fun. Просто посмотреть какие адреса в моей системе резолвятся. Протокол старый, документации должно быть много. Много. Но все статьи очень не полные и заканчиваются, на самом интересном моменте. Да, есть rfc1035, но хотелось бы на русском и с пояснениями. Собственно по накоплению опыта и разбора пакета и созрела данная статья. Она рассчитана на тех, кто понимает, что такое DNS и понимает, что бывают запросы и ответы. Для тех, кто хочет немного разобраться в структуре данного протокола.
Статья предполагает теорию, а потом немного практики.
+---------------------+ | Header | Заголовок +---------------------+ | Question | Секция запросов +---------------------+ | Answer | Секция ответа +---------------------+ | Authority | Секция ответа об уполномоченных серверах +---------------------+ | Additional | Секция ответа дополнительных записей +---------------------+
Header — Заголовок DNS пакета, состоящий из 12 октет.
Question section — в этой секции DNS-клиент передает запросы DNS-серверу сообщая о том, для какого имени необходимо разрешить (зарезолвить) запись DNS, а также какого типа (NS, A, TXT и т.д.). Сервер при ответе, копирует эту информацию и отдает клиенту обратно в этой же секции.
Answer section — сервер сообщает клиенту ответ или несколько ответов на запрос, в котором сообщает вышеуказанные данные.
Authoritative Section — содержит сведения о том, с помощью каких авторитетных серверов было получена информация включенная в секцию DNS-ответа.
Additional Record Section — дополнительные записи, которые относятся к запросу, но не являются строго ответами на вопрос.
Записей в секциях может быть как несколько, так и не быть вообще. Всё определяется заголовком.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ID (16 бит) — данное поле используется как уникальный идентификатор транзакции. Указывает на то, что пакет принадлежит одной и той же сессии “запросов-ответов” и занимает 16 бит.
QR
Opcode (4 бита) — с помощью данного кода клиент может указать тип запроса, где обычное значение:
- 0 — стандартный запрос,
- 1 — инверсный запрос,
- 2 — запрос статуса сервера.
- 3-15 – зарезервированы на будущее.
AA (1 бит) — данное поле имеет смысл только в DNS-ответах от сервера и сообщает о том, является ли ответ авторитетным либо нет.
TC (1 бит) — данный флаг устанавливается в пакете ответе в том случае если сервер не смог поместить всю необходимую информацию в пакет из-за существующих ограничений.
RD (1 бит) — этот однобитовый флаг устанавливается в запросе и копируется в ответ. Если он флаг устанавливается в запросе — это значит, что клиент просит сервер не сообщать ему промежуточных ответов, а вернуть только IP-адрес.
RA (1 бит) — отправляется только в ответах, и сообщает о том, что сервер поддерживает рекурсию
Z (3 бита) — являются зарезервированными и всегда равны нулю.
RCODE (4 бита) — это поле служит для уведомления клиентов о том, успешно ли выполнен запрос или с ошибкой.
- 0 — значит запрос прошел без ошибок;
- 1 — ошибка связана с тем, что сервер не смог понять форму запроса;
- 2 — эта ошибка с некорректной работой сервера имен;
- 3 — имя, которое разрешает клиент не существует в данном домене;
- 4 — сервер не может выполнить запрос данного типа;
- 5 — этот код означает, что сервер не может удовлетворить запроса клиента в силу административных ограничений безопасности.
QDCOUNT(16 бит) – количество записей в секции запросов
ANCOUNT(16 бит) – количество записей в секции ответы
NSCOUNT(16 бит) – количество записей в Authority Section
ARCOUNT(16 бит) – количество записей в Additional Record Section
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / QNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QTYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
QNAME — Каждая запись запроса и ответа начинается с NAME. Это доменное имя, к которому привязана или которому “принадлежит” данная запись. Она закодирована как серия меток. На этом моменте следует остановиться несколько поподробнее.
В статьях, что я видел, забывают сказать, что исходный протокол DNS предусматривает два типа меток, которые определяются первыми двумя битами:
00 (стандартная метка) – значит, остальные 6 бит определяют длину метки, за которым следует данное количество октетов. Соответственно, длина метки не может быть более 63 байта (Например, nslookup выдаст сообщение “is not a legal name (label too long)” при попытке отрезолвить хост с длинной меткой). Заканчивается запись кодом 0x00.
11 (сжатая метка) – тогда последующие 14 бит определяют ссылку на начальный адрес серии меток. Как показал опыт, может так же содержать сжатую метку на другой адрес. В запросе, как правило, таких меток нет.
Так же метка может содержать значение 0x00 (нулевая длина), означает что это корневое доменное имя (root).
Максимальная длина NAME <= 255. Это создано ради простоты реализации.
QTYPE — Тип записи DNS, которую мы ищем (NS, A, TXT и т.д.).
QCLASS — Определяющий класс запроса (IN для Internet).
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NAME — Такой же формат, что и QNAME в секции запроса.
TYPE — тип ресурсной записи. Определяет формат и назначение данной ресурсной записи.
CLASS — класс ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети. В основном IN для Internet (Код 0x0001)
TTL — (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера.
RDLENGTH — длина поля данных (RDATA).
RDATA — поле данных, формат и содержание которого зависит от типа записи.
Рассмотрим пакет из реального запроса и ответа. Запускаем любимый снифер и резолвим habrahabr.ru.
Запрос
Разберем структуру dns заголовка.
ID транзакции = 0x9bce
Далее идут флаги. 01 00 представим как двоичное значение 0’0000’0’0’1’0’000’0000 (здесь и далее я разделяю биты апострофом для лучшего визуального представления деления флагов)
Opcode=0000 – Стандартный запрос;
AA=0 — данное поле имеет смысл только в DNS-ответах, поэтому всегда 0;
TC=0 — данное поле имеет смысл только в DNS-ответах, поэтому всегда 0;
RD=1 – Просим вернуть только IP адрес;
RA=0 – отправляется только сервером;
Z=000 – всегда нули, зарезервированное поле;
RCODE=0000 – Все прошло без ошибок
QDCOUNT=00 01 – 1 запись в секции запросов
ANCOUNT=00 00 – В запросе всегда 0, секция для ответов
NSCOUNT=00 00 – В запросе всегда 0, секция для ответов
ARCOUNT=00 00 – В запросе всегда 0, секция для ответов
Дальше у нас идет секции запросов и ответов. С одной записью.
Первым октетом у нас идет 0x09, представим его как двоичное значение 00’001001. Первые два бита идут 00, это значит что это обычная метка. Длина метки 9 байт (b001001). “68 61 62 72 61 68 61 62 72”. Вот эти 9 байт. Тут написано “habrahabr” (в 16-ричном виде). Идем дальше. Октет 0x02. Первых два бита 00, значит снова обычная метка с длиной 2 байта. Вот они: “72 75”. Написано “ru”. Идем дальше. Октет 0x00. Значит конец записи хоста. Мы получили два слова “habrahabr” и “ru”. Объединяем их точкой, получаем “habrahabr.ru”, это и есть хост который мы запросили.
QCLASS=0x0001 – Соответствует классу IN.
Ответ
Разберем структуру dns заголовка.
ID транзакции = 0x9bce. Она должна быть ровна ID от запроса.
Снова флаги. 81 80 представим как двоичное значение 1’0000’0’0’1’1’000’0000
QR=1 — значит этот пакет является ответом;
Opcode=0000 – Стандартный запрос;
AA=0 – Сервер не является авторитетным для домена;
TC=0 – Вся информация поместилась в один пакет;
RD=1 – Просим вернуть только IP адрес;
Z=000 – всегда нули, зарезервированное поле;
RCODE=0000 – Все прошло без ошибок
QDCOUNT=00 01 – 1 запись в секции запросов
ANCOUNT=00 01 – Теперь у нас появилась одна запись в ответе
NSCOUNT=00 00 – В запросе всегда 0, секция для ответов
ARCOUNT=00 00 – В запросе всегда 0, секция для ответов
Дальше у нас идет секции запросов и ответов. С двумя записями. Одна запись запроса, другая запись с ответом. Расписывать секцию запрос я не буду, он будет всегда 1в1 такой же, как и в пакете запроса. Приступим с секции ответов.
Первым октетом у нас идет 0x09, два первых бита 00, значит обычная метка с длиной 9 байт. Читаем 9 байт, получаем “HABRAHABR”. Далее идет 0XC0 (b11000000). Как видим, первые два бита имеют значение 11, это значит что перед нами сжатая ссылка. Смотрим следующие 8 бит (это у нас 0x16 (b00010110)) и объединяем с текущими последними 6бит. Получаем b00000000010110. Ссылка на 22ой байт пакета DNS (02 72 75 00). Начиная с 22 октета, снова получаем метки. По тем же правилам. У нас это получается “.ru”. Объединяем всё что получили, получается “HABRAHABR.ru” Это и есть хост о котором пойдет дальше речь.
QTYPE = 0x0001 – Соответствует типу A (запрос адреса хоста)
QCLASS = 0x0001 – Соответствует классу IN.
TTL = 0x00000c90 – время актуальности данных 3216 секунд.
RDLENGTH = 0x0004 – Длина данных 4 октета.
RDATA = «b2 f8 ed 44».
Как уже было сказано, формат и содержание зависит от типа записи. Тип записи у нас “A”. Значит, чтобы получить IP мы должны считать 4 байта. Каждый байт это и будет соответствующий октет IP адреса, записанный в 16ричном виде.
Получаем IP: b2.f8.ed.44 или «178.248.237.68». Что и требовалось получить.
Например, для типа NS, формат был бы такой:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+И считывали мы бы имя по правилам QNAME.
Протокол DNS | IT Записки
Обращаясь к другому узлу (например, открывая страницу в браузере идёт обращение к веб-серверу, а при открытии почтовой программы — обращение к почтовому серверу), пользователь может указать адрес узла прямо или косвенно, что, в свою очередь, вынуждает узел пользователя передавать пакет на другой узел. Тем не менее узлы не могут передавать пакеты с указанием имени узла-получателя, поэтому в большинстве сетей для преобразования имён узлов в их IP-адреса используется протокол DNS.
Узел действует как клиент DNS, передавая сообщения серверу DNS по его IP-адресу с указанием необходимого имени узла, на которое сервер отвечает с указанием IP-адреса требуемого узла. После получения информации о соответствии имени узла и его IP-адреса узел отправитель может кэшировать эту информацию чтобы избежать необходимости снова выполнять DNS-запрос при обращении к этому узлу.
Система DNS поддерживает иерархию, соответствующую иерархии зон. Каждая зона сопоставляется с одним (как минимум) авторитетным сервером DNS, на котором расположена информация о домене. Также существует 13 корневых серверов DNS. Это DNS-серверы, содержащие информацию о доменах верхнего уровня, указывающую на DNS-серверы, поддерживающие работу каждого из этих доменов. Корневые серверы обслуживают разные профессиональные организации, многие из этих серверов имеют зеркала, поэтому вывести из строя систему DNS практически невозможно.
Записи DNS бывают разных типов и содержат разную информацию. Основные записи, которые необходимо упомянуть, отображены в таблице 1.
| Тип | Расшифровка | Описание |
| A | Address | Адресная запись, соответствие между именем и IP-адресом |
| CNAME | Canonical name | Каноническое имя для псевдонима (одноуровневая переадресация) |
| NS | Authoritative name server | Адрес узла, отвечающего за доменную зону. Критически важна для функционирования самой системы доменных имён |
| PTR | Domain name pointer | Реализует механизм переадресации |
| SOA | Start of authority | Указание на авторитетность информации, используется для указания на новую зону |
Табл. 1. Основные ресурсные записи DNS
A запись содержит соответствие IP-адреса доменному имени. Используется при разрешении имени узла, например, когда браузеру требуется открыть веб-страницу (по доменному имени). В запросе указывается имя узла, а DNS-сервер в ответе отправляет IP-адрес этого узла, взятый из A записи. В записи содержится IP-адрес.
CNAME записи позволяют задать «псевдоним» или «каноническое имя» для хоста, с целью привязать его не к конкретному IP-адресу, а сослаться на другой хост. Например, если узел имеет несколько доменных имён, достаточно указать одну A запись и ссылаться на неё. В записи содержится доменное имя.
NS записи служат для указания NS-серверов, обслуживающих данную зону и зоны следующего уровня. В записи содержится адрес ответственного DNS сервера.
PTR запись связывает IP хоста с его каноническим именем. Эта запись важна при пересылке почты. В целях уменьшения объема спама многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии. Зачастую, провайдеры интернета создают для IP-адресов своих абонентов автоматически сгенерированные по определённому шаблону PTR-записи. Поэтому при настройке на одном из таких адресов почтового сервера наряду с регистрацией домена у регистратора доменных имён нужно изменять PTR запись на DNS сервере провайдера.
SOA запись содержит информацию о DNS-зоне (имя первичного DNS-сервера зоны, контактный адрес ответственного администратора файла зоны, настройки различных временных интервалов).
Поделиться ссылкой:
21. Протокол dns
DNS(англ.Domain Name System— система доменных имён) — компьютернаяраспределённая системадля получения информации одоменах. Чаще всего используется для получения IP-адреса по именихоста(компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись).
Распределённая база данныхDNS поддерживается с помощью иерархииDNS-серверов, взаимодействующих по определённомупротоколу.
Основой DNS является представление об иерархической структуре доменного имениизонах. Каждый сервер, отвечающий за имя, можетделегироватьответственность за дальнейшую часть домена другому серверу (с административной точки зрения — другой организации или человеку), что позволяет возложить ответственность за актуальность информации на серверы различных организаций (людей), отвечающих только за «свою» часть доменного имени.
Начиная с 2010 года, в систему DNS внедряются средства проверки целостности передаваемых данных, называемые DNS Security Extensions(DNSSEC). Передаваемые данные не шифруются, но их достоверность проверяется криптографическими способами. Внедряемый стандартDANEобеспечивает передачу средствами DNS достоверной криптографической информации (сертификатов), используемых для установления безопасных и защищённых соединенийтранспортногоиприкладногоуровней.
Ключевые характеристики dns
DNS обладает следующими характеристиками:
Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности, и (возможно) адреса корневых DNS-серверов.
Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.
DNS важна для работы Интернета, так как для соединения с узлом необходима информация о егоIP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-серверы, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специальноготекстового файлаhosts, который составлялся централизованно и автоматически рассылался на каждую из машин в своей локальной сети. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS.
DNS была разработана Полом Мокапетрисомв1983 году.
DNS — Википедия
У этого термина существуют и другие значения, см. DNS (значения).| DNS | |
| Название | Domain Name System |
|---|---|
| Уровень (по модели OSI) | Прикладной |
| Семейство | TCP/IP |
| Порт/ID | 53/TCP, 53/UDP |
| Назначение протокола | Разрешение доменных имён |
| Спецификация | RFC 1034, RFC 1035 / STD 13 |
| Основные реализации (клиенты) | Встроен во все сетевые ОС |
| Основные реализации (серверы) | BIND, NSD, PowerDNS или Microsoft DNS Server |
DNS (англ. Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись).
Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу.
Основой DNS является представление об иерархической структуре доменного имени и зонах. Каждый сервер, отвечающий за имя, может делегировать ответственность за дальнейшую часть домена другому серверу (с административной точки зрения — другой организации или человеку), что позволяет возложить ответственность за актуальность информации на серверы различных организаций (людей), отвечающих только за «свою» часть доменного имени.
Начиная с 2010 года в систему DNS внедряются средства проверки целостности передаваемых данных, называемые DNS Security Extensions (DNSSEC). Передаваемые данные не шифруются, но их достоверность проверяется криптографическими способами. Внедряемый стандарт DANE обеспечивает передачу средствами DNS достоверной криптографической информации (сертификатов), используемых для установления безопасных и защищённых соединений транспортного и прикладного уровней.
Ключевые характеристики DNS
DNS обладает следующими характеристиками:
- Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
- Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности, и (возможно) адреса корневых DNS-серверов.
- Кэширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
- Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
- Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.
DNS важна для работы Интернета, так как для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-серверы, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла hosts, который составлялся централизованно и автоматически рассылался на каждую из машин в своей локальной сети. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS.
DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882, RFC 883 и RFC 973 как устаревшие.
Дополнительные возможности
- поддержка динамических обновлений
- защита данных (DNSSEC) и транзакций (TSIG)
- поддержка различных типов информации
История
Использование более простого и запоминающегося имени вместо числового адреса хоста относится к эпохе ARPANET. Стэнфордский исследовательский институт (теперь SRI International) поддерживал текстовый файл HOSTS.TXT, который сопоставлял имена узлов с числовыми адресами компьютеров в ARPANET. Поддержание числовых адресов, называемых списком присвоенных номеров, было обработано Джоном Постелем в Институте информационных наук Университета Южной Калифорнии (ISI), команда которого тесно сотрудничала с НИИ.[1]
Адреса назначались вручную. Чтобы запросить имя хоста и адрес и добавить компьютер в главный файл, пользователи связывались с сетевым информационным центром (NIC) SRI, руководимым Элизабет Фейнлер, по телефону в рабочее время.
К началу 1980-х годов поддержание единой централизованной таблицы хостов стало медленным и громоздким, а развивающейся сети требовалась автоматическая система именования для решения технических и кадровых вопросов. Постел поставил перед собой задачу выработать компромисс между пятью конкурирующими предложениями для решения задачи, сформулированной Полом Мокапетрисом. Мокапетрис вместо этого создал концепцию иерархической системы доменных имен.
Рабочая группа IETF опубликовала оригинальные спецификации в RFC 882 и RFC 883 в ноябре 1983 года.
В 1984 году четыре студента UC Berkeley, Дуглас Терри, Марк Пейнтер, Дэвид Риггл и Сонгниан Чжоу, написали первую версию сервера имен BIND (Berkeley Internet Name Daemon). В 1985 году Кевин Данлэп из DEC существенно пересмотрел реализацию DNS. Майк Карел, Фил Альмквист и Пол Викси поддерживали BIND с тех пор. В начале 1990-х годов BIND был перенесен на платформу Windows NT. Он широко распространен, особенно в Unix-системах, и по-прежнему является наиболее широко используемым программным обеспечением DNS в Интернете.
В ноябре 1987 года были приняты спецификации DNS — RFC 1034 и RFC 1035. После этого были приняты сотни RFC, изменяющих и дополняющих DNS.
Проблемы с безопасностью
Первоначально проблемы безопасности не были основными соображениями при разработке программного обеспечения DNS или любого программного обеспечения для развёртывания в раннем Интернете, поскольку сеть не была открыта для широкой общественности. Однако рост Интернета в коммерческом секторе в 1990-х годах изменил требования к мерам безопасности для защиты целостности данных и аутентификации пользователей.
Несколько уязвимостей были обнаружены и использованы злоумышленниками. Одной из таких проблем является отравление кэша DNS, в котором данные распространяются на кэширующие преобразователи под предлогом того, что они являются авторитетным сервером происхождения, тем самым загрязняя хранилище данных потенциально ложной информацией и длительными сроками действия (время жизни). Впоследствии, запросы легитимных приложений могут быть перенаправлены на сетевые хосты, контролируемые злоумышленником.
DNS-ответы ранее не имели криптографической подписи, что давало возможность для множества вариантов атаки. Современные расширения системы безопасности доменных имен (DNSSEC) изменяют DNS, чтобы добавить поддержку криптографически подписанных ответов. Другие расширения, такие как TSIG, добавляют поддержку криптографической аутентификации между доверенными одноранговыми узлами и обычно используются для авторизации передачи зоны или операций динамического обновления.
Некоторые доменные имена могут использоваться для достижения эффектов спуфинга. Например, paypal.com и paypa1.com — это разные имена, но пользователи могут не различать их в графическом пользовательском интерфейсе в зависимости от выбранного шрифта пользователя. Во многих шрифтах буква l и цифра 1 выглядят очень похожими или даже идентичными. Эта проблема остро стоит в системах, которые поддерживают интернационализированные доменные имена, поскольку многие коды символов в ISO 10646 могут отображаться на типичных экранах компьютеров. Эта уязвимость иногда используется в фишинге.
Для подтверждения результатов DNS также могут использоваться такие методы, как обратный DNS с подтверждением прямых записей, но криптографически достоверными они не являются; при этом не учитывается вариант подмены маршрутной информации (англ. BGP hijacking).
Терминология и принципы работы
Ключевыми понятиями DNS являются:
- Доме́н (англ. domain — область) — узел в дереве имён, вместе со всеми подчинёнными ему узлами (если таковые имеются), то есть именованная ветвь или поддерево в дереве имён. Структура доменного имени отражает порядок следования узлов в иерархии; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости): вверху находится корневой домен (имеющий идентификатор «.»(точка)), ниже идут домены первого уровня (доменные зоны), затем — домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org. домен первого уровня — org, второго — wikipedia, третьего — ru).
- Поддомен (англ. subdomain) — подчинённый домен (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения. Например, если у вас есть домен вида mydomain.ru, вы можете создать для него различные поддомены вида mysite1.mydomain.ru, mysite2.mydomain.ru и т. д.
- Ресурсная запись — единица хранения и передачи информации в DNS. Каждая ресурсная запись имеет имя (то есть привязана к определённому Доменному имени, узлу в дереве имён), тип и поле данных, формат и содержание которого зависит от типа.
- Зона — часть дерева доменных имён (включая ресурсные записи), размещаемая как единое целое на некотором сервере доменных имён (DNS-сервере, см. ниже), а чаще — одновременно на нескольких серверах (см. ниже). Целью выделения части дерева в отдельную зону является передача ответственности (см. ниже) за соответствующий домен другому лицу или организации. Это называется делегированием (см. ниже). Как связная часть дерева, зона внутри тоже представляет собой дерево. Если рассматривать пространство имён DNS как структуру из зон, а не отдельных узлов/имён, тоже получается дерево; оправданно говорить о родительских и дочерних зонах, о старших и подчинённых. На практике большинство зон 0-го и 1-го уровня (‘.’, ru, com, …) состоят из единственного узла, которому непосредственно подчиняются дочерние зоны. В больших корпоративных доменах (2-го и более уровней) иногда встречается образование дополнительных подчинённых уровней без выделения их в дочерние зоны.
- Делегирование — операция передачи ответственности за часть дерева доменных имён другому лицу или организации. За счёт делегирования в DNS обеспечивается распределённость администрирования и хранения. Технически делегирование выражается в выделении этой части дерева в отдельную зону, и размещении этой зоны на DNS-сервере (см. ниже), управляемом этим лицом или организацией. При этом в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны.
- DNS-сервер — специализированное ПО для обслуживания DNS, а также компьютер, на котором это ПО выполняется. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.
- DNS-клиент — специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.
- Авторитетность (англ. authoritative) — признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: авторитетные (когда сервер заявляет, что сам отвечает за зону) и неавторитетные (англ. Non-authoritative), когда сервер обрабатывает запрос, и возвращает ответ других серверов. В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кеширования).
- DNS-запрос (англ. DNS query) — запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным (см. Рекурсия).
Система DNS содержит иерархию DNS-серверов, соответствующую иерархии зон. Каждая зона поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный), на котором расположена информация о домене.
Имя и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.
Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются.[2]
Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP-датаграммы. TCP используется, когда размер данных ответа превышает 512 байт, и для AXFR-запросов.
Рекурсия
Термином Рекурсия в DNS обозначают алгоритм поведения DNS-сервера, при котором сервер выполняет от имени клиента полный поиск нужной информации во всей системе DNS, при необходимости обращаясь к другим DNS-серверам.
DNS-запрос может быть рекурсивным — требующим полного поиска, — и нерекурсивным (или итеративным) — не требующим полного поиска.
Аналогично — DNS-сервер может быть рекурсивным (умеющим выполнять полный поиск) и нерекурсивным (не умеющим выполнять полный поиск). Некоторые программы DNS-серверов, например, BIND, можно сконфигурировать так, чтобы запросы одних клиентов выполнялись рекурсивно, а запросы других — нерекурсивно.
При ответе на нерекурсивный запрос, а также при неумении или запрете выполнять рекурсивные запросы, DNS-сервер либо возвращает данные о зоне, за которую он ответственен, либо возвращает ошибку. Настройки нерекурсивного сервера, когда при ответе выдаются адреса серверов, которые обладают большим объёмом информации о запрошенной зоне, чем отвечающий сервер (чаще всего — адреса корневых серверов), являются некорректными, и такой сервер может быть использован для организации DoS-атак.
В случае рекурсивного запроса DNS-сервер опрашивает серверы (в порядке убывания уровня зон в имени), пока не найдёт ответ или не обнаружит, что домен не существует (на практике поиск начинается с наиболее близких к искомому DNS-серверов, если информация о них есть в кэше и не устарела, сервер может не запрашивать другие DNS-серверы).
Рассмотрим на примере работу всей системы.
Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако сервер DNS может ничего не знать не только о запрошенном имени, но и даже обо всём домене wikipedia.org. В этом случае сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.
В данном случае при разрешении имени, то есть в процессе поиска IP по имени:
- браузер отправил известному ему DNS-серверу рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо пустой ответ и код ошибки NXDOMAIN;
- DNS-сервер, получивший запрос от браузера, последовательно отправлял нерекурсивные запросы, на которые получал от других DNS-серверов ответы, пока не получил ответ от сервера, ответственного за запрошенную зону;
- остальные упоминавшиеся DNS-серверы обрабатывали запросы нерекурсивно (и, скорее всего, не стали бы обрабатывать запросы рекурсивно, даже если бы такое требование стояло в запросе).
Иногда допускается, чтобы запрошенный сервер передавал рекурсивный запрос «вышестоящему» DNS-серверу и дожидался готового ответа.
При рекурсивной обработке запросов все ответы проходят через DNS-сервер, и он получает возможность кэшировать их. Повторный запрос на те же имена обычно не идёт дальше кэша сервера, обращения к другим серверам не происходит вообще. Допустимое время хранения ответов в кэше приходит вместе с ответами (поле TTL ресурсной записи).
Рекурсивные запросы требуют больше ресурсов от сервера (и создают больше трафика), так что обычно принимаются от «известных» владельцу сервера узлов (например, провайдер предоставляет возможность делать рекурсивные запросы только своим клиентам, в корпоративной сети рекурсивные запросы принимаются только из локального сегмента). Нерекурсивные запросы обычно принимаются ото всех узлов сети (и содержательный ответ даётся только на запросы о зоне, которая размещена на узле, на DNS-запрос о других зонах обычно возвращаются адреса других серверов).
Обратный DNS-запрос
DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.
Записи DNS
Записи DNS, или Ресурсные записи (англ. Resource Records, RR) — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей[3]:
- имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
- тип (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи,
- класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети[4],
- TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера,
- длина поля данных (RDLEN),
- поле данных (RDATA), формат и содержание которого зависит от типа записи.
Наиболее важные типы DNS-записей:
- Запись A (address record) или запись адреса связывает имя хоста с адресом протокола IPv4. Например, запрос A-записи на имя referrals.icann.org вернёт его IPv4-адрес — 192.0.34.164.
- Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернёт его IPv6-адрес — 2001:7fd::1.
- Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя.
- Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
- Запись NS (name server) указывает на DNS-сервер для данного домена.
- Запись PTR (pointer[5][6]) обратная DNS-запись или запись указателя связывает IP-адрес хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP-адрес хоста в reverse-форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например (на момент написания), для IP-адреса 192.0.34.164 запрос записи PTR 164.34.0.192.in-addr.arpa вернёт его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP-сессии.
- Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов.
- SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.
Зарезервированные доменные имена
Документ RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.
Интернациональные доменные имена
Доменное имя может состоять только из ограниченного набора ASCII-символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.
Программное обеспечение DNS
Серверы имен:
См. также
Примечания
Ссылки
Статьи
Документы RFC
- RFC 1034 — Domain Names — Concepts and Facilities
- RFC 1035 — Domain Names — Implementation and Specification
- RFC 1912 — Common DNS Operational and Configuration Errors
- RFC 1591 — Domain Name System Structure and Delegation
- RFC 1713 — Tools for DNS Debugging
- RFC 2606 — Reserved Top Level DNS Names
«DNS over HTTPS» оформлен в RFC 8484 — но не все им довольны / ИТ-ГРАД corporate blog / Habr
В конце октября Инженерный совет интернета (IETF) представил стандарт DNS over HTTPS (DoH) для шифрования DNS-трафика, оформив его в виде RFC 8484. Его одобрили многие крупные компании, но были и те, кто остался недоволен решением IETF. Среди последних был один из создателей системы DNS Пол Викси (Paul Vixie). Сегодня мы расскажем, в чем здесь суть.
/ фото Martinelle PD
Проблема DNS
Протокол DNS не шифрует запросы от пользователя к серверу и ответы на них. Данные транслируются в виде текста. Таким образом, запросы содержат имена хостов, которые посещает пользователь. Отсюда появляется возможность «подслушать» канал связи и перехватить незащищенные персональные данные.
В чем суть DNS over HTTPS
Чтобы исправить ситуацию, был предложен стандарт DNS over HTTPS, или «DNS поверх HTTPS». В IETF начали работать над ним в мае 2017 года. Его авторами выступили инженеры Пол Хоффман (Paul Hoffman) из ICANN — корпорации по управлению доменными именами и IP-адресами — и Патрик Макманус (Patrick McManus) из Mozilla.
Особенность DoH заключается в том, что запросы на определение IP-адреса отправляются не DNS-серверу, а инкапсулируются в трафик HTTPS и передаются HTTP-серверу, на котором специальный резолвер обрабатывает их с помощью API. DNS-трафик маскируется под обычный HTTPS-трафик, а связь клиента и сервера происходит через стандартный для HTTPS порт 443. Содержание запросов и факт использования DoH остаются скрытыми.
В RFC 8484 Инженерный совет приводит примеры DNS-запросов к example.com с DoH. Вот запрос с методом GET:
:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB
accept = application/dns-message
Аналогичный запрос с использованием POST:
:method = POST
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query
accept = application/dns-message
content-type = application/dns-message
content-length = 33
<33 bytes represented by the following hex encoding>
00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
01
Многие из представителей ИТ-индустрии выступили в поддержку стандарта IETF. Например, ведущий исследователь интернет-регистратора APNIC Джефф Хьюстон (Geoff Houston).
Разработку протокола поддержали крупные интернет-компании. С начала года (когда протокол еще находился на этапе драфта) DoH тестируют Google/Alphabet и Mozilla. Одно из подразделений Alphabet, выпустило приложение Intra для шифрования DNS-трафика пользователей. Браузер Mozilla Firefox поддерживает DNS over HTTPS с июня этого года.
DoH внедрили и DNS-сервисы — Cloudflare и Quad9. В Cloudflare недавно выпустили приложение (об этом была статья на Хабре) для работы с новым протоколом на Android и iOS. Оно выступает в роли VPN к собственному устройству (на адрес 127.0.0.1). DNS-запросы начинают отправляться в Cloudflare с использованием DoH, а трафик идет «обычным» маршрутом.
Список браузеров и клиентов с поддержкой DoH можно найти на GitHub.
Критика стандарта DoH
Не все участники индустрии положительно отозвались о решении IETF. Противники стандарта считают, что DoH — шаг в неправильном направлении и он только снизит уровень безопасности соединения. Наиболее резко о новом протоколе высказался Пол Викси, один из разработчиков системы DNS. У себя в Twitter он назвал DoH «полнейшей чушью с точки зрения информационной безопасности».
По его мнению, новая технология не даст эффективно контролировать работу сетей. Например, системные администраторы не смогут блокировать потенциально вредоносные сайты, а рядовые пользователи будут лишены возможности организации родительского контроля в браузерах.
/ фото TheAndrasBarta PD
Противники DoH предлагают использовать другой подход — протокол DNS over TLS, или DoT. Эта технология принята как стандарт IETF и описана в документах RFC 7858 и RFC 8310. Как и DoH, протокол DoT скрывает содержимое запросов, но отправляет их не по HTTPS, а использует TLS. Для подключения к DNS-серверу при этом используется отдельный порт — 853. Из-за этого отправка DNS-запроса не скрывается, как в случае с DoH.
Технология DoT тоже подвергается критике. В частности, эксперты отмечают: из-за того, что протокол работает с выделенным портом, третья сторона сможет отслеживать использование защищенного канала и при необходимости блокировать его.
Что ждет протоколы дальше
По словам экспертов, пока неясно, какой из способов защиты DNS-запросов станет более распространен.
Сейчас и Cloudflare, и Quad9, и Alphabet поддерживают оба стандарта. Если DoH Alphabet использует в упомянутом выше приложении Intra, то протокол DoT применили для защиты трафика в Android Pie. Также Google включил поддержку DoH и DoT в Google Public DNS — причем внедрение второго стандарта никак не анонсировали.
Издание The Register пишет, что конечный выбор между DoT и DoH будет зависеть от пользователей и провайдеров, и сейчас ни у одного из стандартов нет явного преимущества. В частности, по прогнозам ИТ-специалистов, для широкого распространения протокола DoH на практике потребуется пара десятилетий.
P.S. Другие материалы из нашего корпоративного блога об IaaS:
P.P.S. Наш канал в Telegram — о технологиях виртуализации:
DNS Службы и Протокол
Сейчас, имея более глубокое понимание того, как приложения обеспечивают интерфейс для пользователя и предоставляют доступ к сети, мы рассмотрим несколько конкретных широко используемых протоколов.
Как мы увидим позже, Транспортный уровень использует схему адресации, применяющую понятие номера порта. Номера портов идентифицируют приложения и службы Прикладного уровня, которые являются источником и назначением данных. Серверные программы как правило используют предопределенные номера портов, которые хорошо известны клиентам.
При рассмотрении различных протоколов и служб TCP/IP Прикладного уровня, мы будем ссылаться на стандартные номера портов TCP и UDP, которые обычно связаны с этими службами. Некоторые из этих служб:
DNS
В информационных сетях устройства маркируются числовыми IP адресами, так чтобы они могли участвовать в отправке и получении сообщений по сети. Однако, человеку весьма неудобно запоминать такие числовые адреса. Поэтому были созданы доменные имена — чтобы конвертировать числовые адреса в простые, легко запоминаемые и узнаваемые имена.
В Интернете эти доменные имена, такие как yandex.ru, людям гораздо легче запомнить, нежели 213.180.193.11, что является фактическим числовым адресом для этого сервера. Кроме того, если адрес сайта google.ru вдруг поменяется, это произойдет незаметно для пользователя, поскольку доменное имя по прежнему останется yandex.ru. Новый адрес просто будет привязан к существующему доменному имени и возможность захода на сайт не пострадает. Когда сети были небольшими, поддержка соответствия между доменными именами и адресами, которые они представляют, была простой задачей. Однако, как только сети начали расти, а количество устройств увеличиваться, эта ручная система стала неработоспособной.
Система Доменных Имен (DNS) была создана вместо доменного имени, чтобы решить проблему разрешения для растущих в размерах сетей. DNS использует распределенный набор серверов для разрешения имен, связанных с этими числовыми адресами.
DNS протокол определяет автоматическую службу, которая сопоставляет имена ресурсов требуемому числовому сетевому адресу. Он включает формат для запросов, ответов, а также форматов данных. Коммуникации DNS протокола используют одиночный формат называемый сообщением. Этот формат сообщения используется для всех типов клиентских запросов и ответов сервера, сообщений об ошибках и для передачи информации о записях ресурсов между серверами.
Далее: Утилита nslookup
Смотрите также
Написать
Что такое DNS, для чего он нужен и как работает
Каждый пользователь интернета знает, для того чтобы попасть на интересующий сайт нужно вбить его адрес — домен в браузере, и он сразу откроется.
Но, как работает эта система? Ведь домен — это не конечный адрес сайта, а лишь имя, которое привязано к IP адресу, на котором он на самом деле и располагается. Как все это функционирует? Все это благодаря — DNS.
Продолжаем рассматривать, как работает интернет, в прошлый раз вы узнали про tcp ip протокол, данный материал будет посвящен ДНС — тому, что это такое и как работает.
Что такое DNS
DNS — это глобальная распределенная система, предназначенная для хранения ключей и значений — доменов. Сервера DNS могут располагаться, где угодно во всемирной паутине, именно поэтому система называется распределенной.
DNS расшифровывается, как — Domain Name System, что в переводе означает — Система доменных имен.
Данная система была разработана с целью облегчения навигации по интернету. Чтобы вместо тяжело запоминающего IP адреса сайта, можно было ввести его название в буквенном формате, т.е. вбить его домен и попасть на него. Ведь всегда лучше запоминаются буквенные значения, а не числовые.
Что такое DNS сервер
DNS сервер, это компьютер, на котором хранится база соответствий доменных имен к IP адресу, именно они выдают вашему браузеру айпи запрашиваемого сайта, чтобы он смог загрузить его. Они могут быть, как локальными, так и глобальными.
ДНС сервер обычно находится у провайдера, но вам ничего не мешает использовать и другие сервисы, например, от Google или от Yandex. Так, например, у того же Яндекса, есть три вида ДНС: базовый, безопасный и семейный. Установив — семейные, вы сможете обезопасить своих детей от порталов для взрослых. Безопасный обеспечит защиту от вредоносных ресурсов, а, базовый — это обычный и надежный вариант.
Интересно! Когда интернет только появился, функцию DNS выполнял файл HOSTS, именно в нем и прописывались значения доменов к айпи. Но, сайтов стало очень много и прописывать из вручную уже было просто некомфортно и долго — их сменили DNS-сервера. Даже сейчас, браузеры на компьютере в первую очередь смотрят этот файл, а уже потом обращаются в ДНС.
Как работает DNS
Каждый ресурс в интернете располагается на каком-либо компьютере — хосте. У каждого такого хоста есть свой собственный уникальный айпи адрес.
Когда вы запрашиваете, какой-либо домен — ключ, например, anisim.org, в вашем браузере, он вначале обращается к ДНС-серверу, который передаст ему — ip адрес, чтобы он открылся. Если на определенном сервере нет информации о домене, то он просит о помощи другой и так до того момента, пока айпи сайта не будет найден.
Как видите, ДНС сильно облегчает серфинг в интернете. Вместо того, чтобы каждый раз вручную вводить IP сайта, можно вбить только его домен.
Дополнительно, данная технология позволяет, чтобы на одном IP могли располагаться сразу несколько сайтов, и наоборот, у одного домена может быть множество IP, а при запросе по домену — откроется именно запрашиваемый ресурс.
Интересно! По айпи можно открыть только те порталы, у которых он уникальный, т.е. на одном адресе — один сайт.
Так как процесс обращения от сервера к другому (если портал не сильно известный), с целью узнать нужный IP занимает время и ресурсы — используется кеш. Провайдеры и ваш браузер кэшируют запросы к сайтам, чтобы вы могли к ним обращаться без ожидания.
DNS записи и зона
Как вы уже поняли, на одном ИП адресе может быть сразу несколько доменов. А к домену могут относится, почтовый сервер или поддомены, которые могут быть совсем на другом IP.
Вся информация о домене, его поддоменах, айпи, почте хранится в ДНС записях. Они бывают разных типов:
A или AAAA — IP адрес самого сайта в IPv4 и IPv6 формате соответственно.
MX — указывает на почтовый шлюз для домена.
CNAME — позволяет указывать синонимы для основного домена, к примеру, если здесь прописать — example.anisim.org CNAME anisim.org — будет перенаправляться на последнюю запись.
NS — это адреса ДНС-серверов обслуживающих домен, обычно их две штуки.
TXT — примечание, если оно необходимо.
На самом деле записей больше, но смысла их все описывать для ознакомления нет — это основные.
Как узнать используемые DNS серверы
1. Нажмите «WIN + R» на клавиатуре, введите ncpa.cpl и нажмите «ОК».
2. Откройте свое подключение к интернету и кликните по кнопке «Сведения». Здесь вы увидите свой DNS-сервер IPv4.
Также, здесь вы можете поменять сервера на тот же Яндекс, для этого:
1. Откройте свойства, кликните по IP версия 4 (TCP/IPv4) и откройте свойства.
2. Вместо автоматического получения DNS-сервера, вбейте их вручную, например, 77.88.8.1 и 77.88.8.8 (смотрите картинку). Это базовые ДНС Yandex.
3. Нажмите «ОК».
Интересно! Довольно удобно использовать сторонние серверы, к примеру, для родительского контроля.
В заключение
Как видите объяснение довольно простое. Постарался все изложить понятным языком, чтобы было, как можно более яснее. Надеюсь вам был полезен данный материал и до встречи на страницах данного портала!