система доменных имен

Система доменных имен ( DNS ) — это иерархическая и распределенная служба имен , которая обеспечивает систему именования компьютеров , служб и других ресурсов в Интернете или других сетях Интернет-протокола (IP). Он связывает различную информацию с доменными именами (идентификационными строками ), присвоенными каждому из связанных объектов. Прежде всего, он преобразует легко запоминаемые доменные имена в числовые IP-адреса , необходимые для поиска и идентификации компьютерных служб и устройств с помощью базовых сетевых протоколов . ^[1] Система доменных имен является важным компонентом функциональности Интернета с 1985 года.

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

Интернет поддерживает два основных пространства имен : иерархию доменных имен и пространство IP-адресов . ^[2]Система доменных имен поддерживает иерархию доменных имен и предоставляет услуги перевода между ней и адресными пространствами. Серверы имен Интернета и протокол связи реализуют систему доменных имен. Сервер имен DNS — это сервер, на котором хранятся записи DNS для домена; DNS-сервер имен отвечает ответами на запросы к своей базе данных.

Наиболее распространенными типами записей, хранящихся в базе данных DNS, являются начальные полномочия ( SOA ), IP-адреса ( A и AAAA ), SMTP почтовые обменники (MX), серверы имен (NS), указатели для обратного поиска DNS (PTR), и псевдонимы доменных имен (CNAME). Хотя DNS не задумывалась как база данных общего назначения, со временем она была расширена для хранения записей для других типов данных либо для автоматического поиска, например записей DNSSEC , либо для ручных запросов, таких как записи ответственных лиц (RP). В качестве базы данных общего назначения DNS также используется для борьбы с нежелательной электронной почтой (спамом) путем хранения списка «черных дыр» в реальном времени (RBL). База данных DNS традиционно хранится в структурированном текстовом файле, файле зоны , но распространены и другие системы баз данных.

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

Функция [ править ]

Часто используемая аналогия для объяснения DNS заключается в том, что он служит телефонной книгой в Интернете, преобразуя понятные для человека имена компьютеров в IP-адреса. Например, имя хоста www.example.comвнутри доменного имени example.com преобразуется в адреса 93.184.216.34 ( IPv4 ) и 2606:2800:220:1:248:1893:25c8:1946 ( IPv6 ). DNS можно быстро и прозрачно обновлять, позволяя изменять местоположение службы в сети, не затрагивая конечных пользователей, которые продолжают использовать то же имя хоста. Пользователи пользуются этим, когда используют осмысленные унифицированные указатели ресурсов ( URL-адреса ) и адреса электронной почты , не зная, как компьютер на самом деле находит службы.

Важной и повсеместной функцией DNS является ее центральная роль в распределенных интернет-сервисах, таких как облачные сервисы и сети доставки контента . ^[3]Когда пользователь обращается к распределенной интернет-службе с помощью URL-адреса, доменное имя URL- адреса преобразуется в IP-адрес сервера, находящегося рядом с пользователем. Основная функциональность DNS, использованная здесь, заключается в том, что разные пользователи могут одновременно получать разные переводы одного и того же доменного имени, что является ключевым моментом отклонения от традиционного представления DNS в виде телефонной книги. Этот процесс использования DNS для назначения пользователям ближайших серверов является ключом к обеспечению более быстрых и надежных ответов в Интернете и широко используется большинством основных интернет-сервисов. ^[4]

DNS отражает структуру административной ответственности в Интернете. ^[5]Каждый субдомен представляет собой зону административной автономии, делегированную менеджеру. Для зон, управляемых реестром , административная информация часто дополняется службами реестра RDAP и WHOIS . Эти данные можно использовать для получения информации о конкретном хосте в Интернете и отслеживания ответственности за него. ^[6]

История [ править ]

Использование более простого и запоминающегося имени вместо числового адреса хоста восходит к эпохе ARPANET . Стэнфордский исследовательский институт (ныне SRI International ) поддерживал текстовый файл с именем HOSTS.TXT , который сопоставлял имена хостов с числовыми адресами компьютеров в сети ARPANET. ^[7]^[8] Элизабет Фейнлер разработала и поддерживала первый каталог ARPANET. ^[9]^[10] Обслуживанием числовых адресов, называемым списком присвоенных номеров, занимался Джон Постел из Южной Калифорнии Университета Института информационных наук (ISI), чья команда тесно сотрудничала с SRI. ^[11]

Адреса были назначены вручную. Компьютеры, включая их имена хостов и адреса, были добавлены в основной файл путем обращения в сетевой информационный центр SRI (NIC), которым руководил Фейнлер, по телефону в рабочее время. ^[12] Позже Фейнлер создал каталог WHOIS на сервере сетевого адаптера для получения информации о ресурсах, контактах и объектах. ^[13] Она и ее команда разработали концепцию доменов. ^[13] Фейнлер предложил, чтобы домены основывались на расположении физического адреса компьютера. ^[14] компьютеры в учебных заведениях будут иметь домен edu . Например, ^[15] Она и ее команда управляли реестром имен хостов с 1972 по 1989 год. ^[16]

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

Инженерная группа Интернета опубликовала исходные спецификации в RFC 882 и RFC 883 в ноябре 1983 года. ^[18]^[19] Они были обновлены в RFC 973 в январе 1986 года.

В 1984 году четыре студента Калифорнийского университета в Беркли , Дуглас Терри, Марк Пейнтер, Дэвид Риггл и Суннянь Чжоу, написали первую Unix реализацию сервера имен для домена имен Интернета Беркли, обычно называемого BIND . ^[20]В 1985 году Кевин Данлэп из DEC существенно пересмотрел реализацию DNS. Затем Майк Карелс , Фил Алмквист и Пол Викси взяли на себя обслуживание BIND. Консорциум Internet Systems был основан в 1994 году Риком Адамсом , Полом Викси и Карлом Маламудом специально для того, чтобы предоставить базу для разработки и обслуживания BIND. Версии BIND, начиная с 4.9.3, разрабатывались и поддерживались ISC при поддержке спонсоров ISC. В качестве соархитекторов/программистов Боб Хэлли и Пол Викси выпустили первую готовую к производству версию BIND версии 8 в мае 1997 года. С 2000 года над BIND работали более 43 различных основных разработчиков. ^[21]

В ноябре 1987 г. RFC 1034 ^[22] и RFC 1035 ^[5]заменил спецификации DNS 1983 года. В нескольких дополнительных запросах на комментарии были предложены расширения основных протоколов DNS. ^[23]

Структура [ править ]

Пространство доменных имен [ править ]

Пространство доменных имен состоит из древовидной структуры данных . Каждый узел или лист дерева имеет метку и ноль или более записей ресурсов (RR), которые содержат информацию, связанную с именем домена. Само доменное имя состоит из метки, объединенной с именем родительского узла справа, разделенных точкой. ^[24]

Дерево подразделяется на зоны, начиная с корневой зоны . Зона DNS может состоять из любого количества доменов и поддоменов по выбору менеджера зоны. DNS также можно разделить по классам , при этом отдельные классы можно рассматривать как массив параллельных деревьев пространств имен. ^[25]

Административная ответственность за любую зону может быть разделена путем создания дополнительных зон. Сообщается, что полномочия над новой зоной будут делегированы назначенному серверу имен. Родительская зона перестает быть авторитетной для новой зоны. ^[25]

Синтаксис доменного имени, интернационализация [ править ]

Подробные описания правил формирования доменных имен содержатся в RFC 1035, RFC 1123, RFC 2181 и RFC 5892. Доменное имя состоит из одной или нескольких частей, технически называемых метками , которые обычно объединяются и разделяются точками, например как например.com.

Крайняя правая метка обозначает домен верхнего уровня ; например, доменное имя www.example.com принадлежит домену верхнего уровня com .

Иерархия доменов спускается справа налево; каждая метка слева указывает подразделение или поддомен домена справа. Например, в примере метки указан субдомен домена com , а www — это субдомен example.com. Это дерево подразделений может иметь до 127 уровней. ^[26]

Метка может содержать от 0 до 63 символов. Нулевая метка нулевой длины зарезервирована для корневой зоны. Полное доменное имя не может превышать длину 253 символов в своем текстовом представлении. ^[22] Во внутреннем двоичном представлении DNS максимальная длина требует 255 октетов памяти, поскольку она также хранит длину имени. ^[5]

Хотя не существует технических ограничений, запрещающих использование в метках доменных имен любых символов, представленных октетами, имена хостов используют предпочтительный формат и набор символов. Символы, разрешенные в метках, представляют собой подмножество набора символов ASCII , состоящего из символов от a до z , от A до Z , цифр от 0 до 9 и дефиса. Это правило известно как правило LDH (буквы, цифры, дефис). Доменные имена интерпретируются независимо от регистра. ^[27] Метки не могут начинаться или заканчиваться дефисом. ^[28] Дополнительное правило требует, чтобы доменные имена верхнего уровня не были полностью цифровыми. ^[28]

Ограниченный набор символов ASCII, разрешенный в DNS, препятствовал представлению имен и слов многих языков в их родных алфавитах или алфавитах. Чтобы сделать это возможным, ICANN одобрила систему интернационализации доменных имен в приложениях (IDNA), с помощью которой пользовательские приложения, такие как веб-браузеры, сопоставляют строки Unicode с допустимым набором символов DNS с помощью Punycode . В 2009 году ICANN одобрила установку интернационализированных доменных имен с кодами стран и доменами верхнего уровня ( ccTLD ) . Кроме того, многие реестры существующих доменных имен верхнего уровня ( TLD ) приняли систему IDNA, руководствуясь RFC 5890, RFC 5891, RFC 5892, RFC 5893.

Серверы имен [ править ]

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

Авторитетный сервер имен [ править ]

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

Авторитетный сервер имен может быть либо первичным , либо вторичным сервером. Исторически термины «главный/подчиненный» и «первичный/вторичный» иногда использовались как синонимы. ^[29]но в настоящее время используется последняя форма. Первичный сервер — это сервер, на котором хранятся исходные копии всех записей зоны. Вторичный сервер использует специальный механизм автоматического обновления протокола DNS при взаимодействии со своим основным сервером для поддержания идентичной копии первичных записей.

Каждой зоне DNS должен быть назначен набор авторитетных серверов имен. Этот набор серверов хранится в родительской доменной зоне с записями сервера имен (NS).

Авторитетный сервер указывает свой статус предоставления окончательных ответов, считающихся авторитетными , путем установки флага протокола, называемого « Авторитетный ответ » ( AA ) битом , в своих ответах. ^[5] Этот флаг обычно воспроизводится заметно в выходных данных инструментов администрирования DNS, таких как dig , чтобы указать , что отвечающий сервер имен является уполномоченным для рассматриваемого доменного имени. ^[5]

Когда сервер имен назначается авторитетным сервером для доменного имени, для которого он не имеет авторитетных данных, он представляет тип ошибки, называемый «неубедительным делегированием» или «неубедительным ответом». ^[30]^[31]

Операция [ править ]

Механизм разрешения адресов [ править ]

Резолверы доменных имен определяют серверы доменных имен, ответственные за рассматриваемое доменное имя, с помощью последовательности запросов, начиная с самой правой (верхнего уровня) метки домена.

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

Предполагая, что у преобразователя нет кэшированных записей для ускорения процесса, процесс разрешения начинается с запроса к одному из корневых серверов. При типичной работе корневые серверы не отвечают напрямую, а направляют ссылку на более авторитетные серверы, например, запрос «www.wikipedia.org» перенаправляется на серверы организации . Теперь преобразователь запрашивает упомянутые серверы и итеративно повторяет этот процесс, пока не получит достоверный ответ. На диаграмме показан этот процесс для хоста, названного полным доменным именем «www.wikipedia.org».

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

Рекурсивный и кеширующий сервер имен [ править ]

Теоретически для работы Интернета достаточно авторитетных серверов имен. Однако, поскольку работают только авторитетные серверы имен, каждый DNS-запрос должен начинаться с рекурсивных запросов в корневой зоне системы доменных имен, и каждая пользовательская система должна будет реализовать программное обеспечение преобразователя, способное выполнять рекурсивные операции. ^[32]

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

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

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

Резолверы DNS [ править ]

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

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

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

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

Круговые зависимости и склеивающие записи [ править ]

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

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

Например, если авторитетным сервером имен для example.org является ns1.example.org, компьютер, пытающийся разрешить www.example.org, сначала разрешает ns1.example.org. Поскольку ns1 содержится в example.org, сначала необходимо разрешить example.org, что представляет собой циклическую зависимость. Чтобы разорвать эту зависимость, сервер имен для доменной организации верхнего уровня включает связку вместе с делегированием для example.org. Связывающие записи — это записи адресов, которые предоставляют IP-адреса для ns1.example.org. Резолвер использует один или несколько из этих IP-адресов для запроса одного из авторитетных серверов домена, что позволяет ему выполнить DNS-запрос.

Кэширование записей [ править ]

Стандартной практикой реализации разрешения имен в приложениях является снижение нагрузки на серверы системы доменных имен путем кэширования результатов локально или на промежуточных узлах преобразователя. Результаты, полученные по запросу DNS, всегда связаны со временем жизни (TTL), сроком действия, по истечении которого результаты должны быть удалены или обновлены. TTL устанавливается администратором авторитетного DNS-сервера. Срок действия может варьироваться от нескольких секунд до дней и даже недель. ^[33]

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

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

Обратный поиск [ править ]

Обратный поиск DNS — это запрос DNS на предмет доменных имен, когда IP-адрес известен. С одним IP-адресом может быть связано несколько доменных имен. DNS хранит IP-адреса в форме доменных имен в виде специально отформатированных имен в записях указателей (PTR) в домене верхнего уровня инфраструктуры arpa . Для IPv4 домен — in-addr.arpa. Для IPv6 домен обратного просмотра — ip6.arpa. IP-адрес представлен как имя в октетном представлении в обратном порядке для IPv4 и в виде полубайтового представления в обратном порядке для IPv6.

При выполнении обратного поиска DNS-клиент преобразует адрес в эти форматы перед запросом имени для записи PTR, следующей за цепочкой делегирования, как и для любого DNS-запроса. Например, если предположить, что IPv4-адрес 208.80.152.2 назначен Wikimedia, он будет представлен как DNS-имя в обратном порядке: 2.152.80.208.in-addr.arpa. Когда распознаватель DNS получает запрос указателя (PTR), он начинает с запроса корневых серверов, которые указывают на серверы Американского реестра номеров Интернета (ARIN) для зоны 208.in-addr.arpa. Серверы ARIN делегируют адрес 152.80.208.in-addr.arpa Викимедиа, которому распознаватель отправляет еще один запрос на 2.152.80.208.in-addr.arpa, что приводит к получению авторитетного ответа.

Поиск клиентов [ править ]

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

Распознаватель DNS почти всегда имеет кэш (см. выше), содержащий недавние запросы. Если кеш может предоставить ответ на запрос, преобразователь вернет значение из кеша программе, сделавшей запрос. Если в кэше нет ответа, преобразователь отправит запрос на один или несколько назначенных DNS-серверов. В случае большинства домашних пользователей этот DNS-сервер обычно предоставляет поставщик интернет-услуг, к которому подключается машина: такой пользователь либо настроит адрес этого сервера вручную, либо разрешит DHCP установить его; однако, если системные администраторы настроили системы на использование собственных DNS-серверов, их преобразователи DNS указывают на отдельно поддерживаемые серверы имен организации. В любом случае запрошенный таким образом сервер имен будет следовать процессу, описанному выше , до тех пор, пока он либо успешно не найдет результат, либо нет. Затем он возвращает свои результаты преобразователю DNS; предполагая, что он нашел результат, распознаватель должным образом кэширует этот результат для будущего использования и передает результат обратно программному обеспечению, инициировавшему запрос.

Сломанные резольверы [ править ]

Некоторые крупные интернет-провайдеры настроили свои DNS-серверы на нарушение правил, например, не соблюдая TTL или указывая, что доменное имя не существует только потому, что один из его серверов имен не отвечает. ^[34]

Некоторые приложения, такие как веб-браузеры, поддерживают внутренний кэш DNS, чтобы избежать повторных поисков через сеть. Эта практика может добавить дополнительные трудности при отладке проблем DNS, поскольку она скрывает историю таких данных. Эти кэши обычно используют очень короткое время кэширования, порядка одной минуты. ^[35]

Internet Explorer представляет собой заметное исключение: версии до IE 3.x по умолчанию кэшируют записи DNS в течение 24 часов. Internet Explorer 4.x и более поздние версии (вплоть до IE 8) уменьшают значение времени ожидания по умолчанию до получаса, которое можно изменить, изменив конфигурацию по умолчанию. ^[36]

Когда Google Chrome обнаруживает проблемы с DNS-сервером, он отображает определенное сообщение об ошибке.

Другие приложения [ править ]

Система доменных имен включает в себя несколько других функций и возможностей.

Имена хостов и IP-адреса не обязательно должны совпадать в отношении «один к одному». Несколько имен хостов могут соответствовать одному IP-адресу, что полезно при виртуальном хостинге , когда множество веб-сайтов обслуживаются с одного хоста. Альтернативно, одно имя хоста может разрешаться во множество IP-адресов, чтобы обеспечить отказоустойчивость и распределение нагрузки между несколькими экземплярами серверов на предприятии или в глобальном Интернете.

Помимо преобразования имен в IP-адреса, DNS служит и другим целям. Например, агенты передачи почты используют DNS, чтобы найти лучший почтовый сервер для доставки электронной почты : запись MX обеспечивает сопоставление между доменом и почтовым обменником; это может обеспечить дополнительный уровень отказоустойчивости и распределения нагрузки.

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

Например:

Адрес 203.0.113.5 занесен в черный список. Это указывает на 5.113.0.203.blacklist.example , который разрешается в 127.0.0.1 .
Адрес 203.0.113.6 не занесен в черный список и указывает на 6.113.0.203.черный список.пример . Это имя хоста либо не настроено, либо разрешается в 127.0.0.2 .

Серверы электронной почты могут запрашивать файл blacklist.example, чтобы узнать, находится ли в черном списке конкретный хост, подключающийся к ним. Многие из таких черных списков, как по подписке, так и бесплатно, доступны для использования администраторами электронной почты и программами защиты от спама.

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

Динамический DNS (DDNS) обновляет DNS-сервер с IP-адресом клиента «на лету», например, при перемещении между интернет-провайдерами или мобильными точками доступа или при административном изменении IP-адреса.

Формат DNS-сообщения [ править ]

Протокол DNS использует два типа сообщений DNS: запросы и ответы; оба имеют одинаковый формат. Каждое сообщение состоит из заголовка и четырех разделов: вопрос, ответ, авторитет и дополнительное пространство. Поле заголовка ( флаги ) управляет содержимым этих четырех разделов. ^[22]

Раздел заголовка состоит из следующих полей: «Идентификация» , «Флаги» , «Количество вопросов» , «Количество ответов» , «Количество записей авторитетных ресурсов» (RR) и «Количество дополнительных RR» . Каждое поле имеет длину 16 бит и отображается в указанном порядке. Поле идентификации используется для сопоставления ответов с запросами. Поле флага состоит из следующих подполей:

Формат флагов заголовка
Поле	Описание	Длина ( биты )
QR-код	Указывает, является ли сообщение запросом (0) или ответом (1).	1
КОД ОПЕРАЦИИ	Тип может быть QUERY (стандартный запрос, 0), IQUERY (обратный запрос, 1) или STATUS (запрос состояния сервера, 2).	4
АА	Авторитетный ответ в ответе указывает, является ли DNS-сервер авторитетным для запрошенного имени хоста.	1
ТК	TrunCation указывает, что это сообщение было усечено из-за чрезмерной длины.	1
РД	Требуется рекурсия: указывает, имеет ли клиент в виду рекурсивный запрос.	1
ДА	Доступная рекурсия в ответе указывает, поддерживает ли отвечающий DNS-сервер рекурсию.	1
С	Ноль, зарезервировано для будущего использования	3
RCODE	Код ответа может быть NOERROR (0), FORMERR (1, ошибка формата), SERVFAIL (2), NXDOMAIN (3, несуществующий домен) и т. д. ^[37]	4

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

DNS-заголовок
Смещения		0								1								2								3
Октет	Кусочек	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7	0	1	2	3	4	5	6	7
0	0	ID транзакции																Флаги
0	0	ID транзакции																QR-код	КОД ОПЕРАЦИИ				АА	ТК	РД	ДА	С			RCODE
4	32	Количество вопросов																Количество ответов
8	64	Количество авторитетных RR																Количество дополнительных RR

Раздел вопросов [ править ]

Раздел вопросов имеет более простой формат, чем формат записи ресурсов, используемый в других разделах. Каждая запись вопроса (обычно в разделе только одна) содержит следующие поля:

Поля записи ресурса (RR)
Поле	Описание	Длина ( октеты )
ИМЯ	Название запрошенного ресурса	Переменная
ТИП	Тип RR (A, AAAA, MX, TXT и т. д.)	2
СОРТ	Код класса	2

Доменное имя разбито на отдельные метки, которые объединяются; каждой метке предшествует длина этой метки. ^[38]

Записи ресурсов [ править ]

Система доменных имен определяет базу данных информационных элементов для сетевых ресурсов. Типы информационных элементов распределены по категориям и организованы с помощью списка типов записей DNS , записей ресурсов (RR). Каждая запись имеет тип (имя и номер), срок действия ( время жизни ), класс и данные, специфичные для типа. Записи ресурсов одного типа описываются как набор записей ресурсов (RRset), не имеющий специального порядка. Резолверы DNS возвращают весь набор по запросу, но серверы могут реализовать циклическое упорядочение для достижения балансировки нагрузки . Напротив, расширения безопасности системы доменных имен (DNSSEC) работают с полным набором записей ресурсов в каноническом порядке.

При отправке по сети Интернет-протокола все записи используют общий формат, указанный в RFC 1035: ^[39]

Поля записи ресурса (RR)
Поле	Описание	Длина ( октеты )
ИМЯ	Имя узла, к которому относится эта запись	Переменная
ТИП	Тип записи в числовой форме (например, 15 для записей MX)	2
СОРТ	Код класса	2
ТТЛ	Количество секунд, в течение которых RR остается действительным (максимум — 2 ³¹−1, что составляет около 68 лет)	4
ДЛИНА	Длина поля RDATA (указанная в октетах)	2
РДАТА	Дополнительные данные, относящиеся к RR	Переменная, согласно RDLENGTH

NAME — полное доменное имя узла в дереве. ^{[ нужны разъяснения ]}. В проводном режиме имя может быть сокращено с помощью сжатия меток, при котором концы доменных имен, упомянутых ранее в пакете, могут быть заменены концом текущего доменного имени.

TYPE — тип записи. Он указывает формат данных и намекает на их предполагаемое использование. Например, запись A используется для преобразования имени домена в адрес IPv4 , запись NS перечисляет, какие серверы имен могут отвечать на запросы в зоне DNS , а запись MX указывает почтовый сервер, используемый для обработки почты для указанного домена. в адресе электронной почты.

RDATA — это данные, относящиеся к конкретному типу, например IP-адрес для записей адреса или приоритет и имя хоста для записей MX. Хорошо известные типы записей могут использовать сжатие меток в поле RDATA, а «неизвестные» типы записей — нет (RFC 3597).

CLASS ) для общих записей DNS , записи имеет значение IN (для Интернета включающих имена хостов, серверы или IP-адреса Интернета. Кроме того, существуют классы Хаос (CH) и Гесиод (HS). ^[40] Каждый класс представляет собой независимое пространство имен с потенциально различным делегированием зон DNS.

В дополнение к записям ресурсов, определенным в файле зоны , система доменных имен также определяет несколько типов запросов, которые используются только при обмене данными с другими узлами DNS ( по проводу ), например, при выполнении зонной передачи (AXFR/IXFR) или для EDNS. (ОПТ).

Записи с подстановочными знаками [ править ]

Система доменных имен поддерживает записи DNS с подстановочными знаками , которые определяют имена, начинающиеся со звездочки . *, например, *.example. ^[22]^[41]Записи DNS, принадлежащие доменным именам с подстановочными знаками, определяют правила создания записей ресурсов в одной зоне DNS путем замены целых меток соответствующими компонентами имени запроса, включая любых указанных потомков. Например, в следующей конфигурации DNS-зона x.example указывает, что все субдомены, включая субдомены субдоменов, x.example используют почтовый обменник (MX) axexample . Запись A для axexample необходима для указания IP-адреса почтового обменника. Поскольку это приводит к исключению этого доменного имени и его поддоменов из совпадений с подстановочными знаками, в зоне DNS также необходимо определить дополнительную запись MX для поддомена axexample , а также запись MX с подстановочными знаками для всех его поддоменов.

x.пример.          MX     10   a.x.пример. 
  *.x.пример.        MX     10   a.x.пример. 
  *.axпример.      MX     10   a.x.пример. 
  топорпример.        MX     10   a.x.пример. 
  топорпример.        АААА   2001:db8::1

Роль групповых записей была уточнена в RFC 4592 , поскольку исходное определение в RFC 1034 был неполным и приводил к неправильному толкованию разработчиками. ^[41]

Расширения протокола [ править ]

Исходный протокол DNS имел ограниченные возможности для расширения новыми функциями. В 1999 году Пол Викси опубликовал в RFC 2671 (замененном RFC 6891) механизм расширения, названный « Механизмы расширения для DNS» (EDNS), который ввел дополнительные элементы протокола без увеличения накладных расходов, когда они не используются. Это было достигнуто с помощью записи псевдоресурса OPT, которая существует только при проводной передаче протокола, но не в каких-либо файлах зон. Также были предложены первоначальные расширения (EDNS0), такие как увеличение размера сообщения DNS в дейтаграммах UDP.

Обновления динамической зоны [ править ]

Обновления динамического DNS используют код операции UPDATE DNS для динамического добавления или удаления записей ресурсов из базы данных зоны, хранящейся на авторитетном DNS-сервере. ^[42]Эта возможность полезна для регистрации сетевых клиентов в DNS, когда они загружаются или иным образом становятся доступными в сети. Поскольку загрузочному клиенту каждый раз может быть назначен другой IP-адрес от DHCP- сервера, невозможно обеспечить статические назначения DNS для таких клиентов.

Транспортные протоколы [ править ]

С момента своего создания в 1983 году DNS использовала протокол пользовательских датаграмм (UDP) для передачи данных по IP. Его ограничения послужили стимулом для многочисленных разработок протоколов в последующие десятилетия с точки зрения надежности, безопасности, конфиденциальности и других критериев.

DNS поверх UDP/TCP/53 (Do53) [ править ]

UDP резервирует порт номер 53 для серверов, прослушивающих запросы. ^[5]Такие запросы состоят из запроса в виде открытого текста, отправленного в одном пакете UDP от клиента, на который отвечает ответ в виде открытого текста, отправленный в одном пакете UDP от сервера. Если длина ответа превышает 512 байт и клиент и сервер поддерживают механизмы расширения DNS (EDNS), можно использовать UDP-пакеты большего размера. ^[43]Использование DNS поверх UDP ограничено, среди прочего, отсутствием шифрования транспортного уровня, аутентификации, надежной доставки и длины сообщения. В 1989 году RFC 1123 определил дополнительный транспорт протокола управления передачей (TCP) для DNS-запросов, ответов и, в частности, зонной передачи . Благодаря фрагментации длинных ответов TCP обеспечивает более длинные ответы, надежную доставку и повторное использование долгоживущих соединений между клиентами и серверами. Для более крупных ответов сервер направляет клиента к транспорту TCP.

DNS через TLS (DoT) [ править ]

DNS поверх TLS появился в качестве стандарта IETF для зашифрованного DNS в 2016 году, в котором используется безопасность транспортного уровня (TLS) для защиты всего соединения, а не только полезной нагрузки DNS. Серверы DoT прослушивают TCP-порт 853. RFC 7858 указывает, что могут поддерживаться оппортунистическое шифрование и шифрование с проверкой подлинности, но не делает обязательной аутентификацию сервера или клиента.

DNS через HTTPS (DoH) [ править ]

DNS over HTTPS был разработан в качестве конкурирующего стандарта для передачи DNS-запросов в 2018 году, туннелируя данные DNS-запросов через HTTPS, что обеспечивает передачу HTTP через TLS. DoH рекламировался как более удобная для Интернета альтернатива DNS, поскольку, как и DNSCrypt, он использует TCP-порт 443 и, таким образом, похож на веб-трафик, хотя на практике их легко дифференцировать без надлежащего заполнения. ^[44]

DNS через QUIC (DoQ) [ править ]

RFC 9250, опубликованный в 2022 году Internet Engineering Task Force , описывает DNS через QUIC . Он имеет «свойства конфиденциальности, аналогичные DNS через TLS (DoT) [...], и характеристики задержки, аналогичные классическому DNS через UDP». Этот метод отличается от DNS через HTTP/3 . ^[45]

Oblivious DoH (ODoH) и предшественник Oblivious DNS ( ODNS )

Oblivious DNS (ODNS) был изобретен и реализован исследователями из Принстонского университета и Чикагского университета как расширение незашифрованного DNS. ^[46]до того, как DoH был стандартизирован и широко распространен. Впоследствии Apple и Cloudflare применили эту технологию в контексте DoH под названием Oblivious DoH (ODoH). ^[47] ODoH сочетает в себе разделение входящего и исходящего трафика (изобретенное в ODNS) с туннелированием HTTPS DoH и шифрованием транспортного уровня TLS в одном протоколе. ^[48]

DNS через Tor [ править ]

DNS может работать через виртуальные частные сети (VPN) и протоколы туннелирования . Использование, которое стало распространенным с 2019 года, чтобы гарантировать собственную часто используемую аббревиатуру, — DNS over Tor . Повышение конфиденциальности Oblivious DNS может быть достигнуто за счет использования существующей сети входящих и выходных узлов Tor в сочетании с шифрованием транспортного уровня, обеспечиваемым TLS. ^[49]

DNSCrypt [ править ]

Протокол DNSCrypt , который был разработан в 2011 году вне структуры стандартов IETF , представил шифрование DNS на нисходящей стороне рекурсивных преобразователей, в котором клиенты шифруют полезные данные запроса с использованием открытых ключей серверов, которые публикуются в DNS (вместо того, чтобы полагаться на третьи данные). центры сертификации сторон), которые, в свою очередь, могут быть защищены подписями DNSSEC. ^[50]DNSCrypt использует порт 443 TCP или UDP, тот же порт, что и веб-трафик, зашифрованный по протоколу HTTPS. Это обеспечило не только конфиденциальность содержимого запроса, но и значительную степень возможности обхода брандмауэра. В 2019 году DNSCrypt был расширен для поддержки «анонимного» режима, аналогичного предложенному «Забывчивому DNS», в котором входной узел получает запрос, зашифрованный открытым ключом другого сервера, и передает его этому сервер, который действует как выходной узел, выполняя рекурсивное разрешение. ^[51]Создается конфиденциальность пар пользователь/запрос, поскольку входной узел не знает содержимого запроса, а выходные узлы не знают личности клиента. DNSCrypt был впервые реализован OpenDNS в декабре 2011 года. Существует несколько бесплатных реализаций программного обеспечения с открытым исходным кодом, которые дополнительно интегрируют ODoH. ^[52] Он доступен для различных операционных систем, включая Unix, Apple iOS, Linux, Android и MS Windows.

Проблемы безопасности [ править ]

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

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

Ответы DNS традиционно не имеют криптографической подписи , что открывает множество возможностей для атак; ( Расширения безопасности системы доменных имен DNSSEC) изменяют DNS, добавляя поддержку ответов с криптографической подписью. ^[53] DNSCurve был предложен в качестве альтернативы DNSSEC. Другие расширения, такие как TSIG , добавляют поддержку криптографической аутентификации между доверенными узлами и обычно используются для авторизации передачи зоны или операций динамического обновления.

Некоторые доменные имена могут использоваться для достижения эффекта подделки. Например, PayPal.com и paypa1.com — это разные имена, однако пользователи могут не различить их в графическом интерфейсе пользователя в зависимости от выбранного пользователем шрифта . Во многих шрифтах буква л и цифра 1 выглядят очень похоже или даже идентично. Эта проблема, известная как атака омографа IDN , остро стоит в системах, поддерживающих интернационализированные доменные имена , поскольку многие коды символов в ISO 10646 могут выглядеть идентичными на обычных компьютерных экранах. Эта уязвимость иногда используется при фишинге . ^[54]

такие методы, как обратный DNS с прямым подтверждением Для проверки результатов DNS также можно использовать .

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

Проблемы конфиденциальности и отслеживания [ править ]

Первоначально разработанный как общедоступная, иерархическая, распределенная и сильно кэшированная база данных, протокол DNS не имеет средств контроля конфиденциальности. Пользовательские запросы и ответы серверов имен передаются в незашифрованном виде, что позволяет перехватывать сетевые пакеты , перехватывать DNS , заражать кэш DNS и атаковать посредника . Этот недостаток обычно используется киберпреступниками и сетевыми операторами в маркетинговых целях, аутентификации пользователей на каптивных порталах и цензуре . ^[55]

Конфиденциальность пользователей дополнительно раскрывается благодаря предложениям по повышению уровня информации об IP-адресах клиентов в DNS-запросах (RFC 7871) в интересах сетей доставки контента .

Основные подходы, используемые для решения проблем конфиденциальности с помощью DNS:

VPN , которые передают разрешение DNS оператору VPN и скрывают пользовательский трафик от местного интернет-провайдера.
Tor , который заменяет традиционное разрешение DNS анонимными доменами .onion , скрывая как разрешение имен, так и пользовательский трафик за луковой маршрутизации , контрнаблюдением
Прокси-серверы и общедоступные DNS-серверы, которые передают фактическое разрешение DNS стороннему поставщику, который обычно обещает небольшую регистрацию запросов или вообще ее отсутствие, а также дополнительные дополнительные функции, такие как реклама на уровне DNS или блокировка порнографии.
- Публичные DNS-серверы можно запрашивать с использованием традиционного протокола DNS, и в этом случае они не обеспечивают защиту от локального наблюдения, или DNS через HTTPS , DNS через TLS и DNSCrypt , которые обеспечивают такую защиту.

Решения, предотвращающие проверку DNS оператором местной сети, подвергаются критике за нарушение политики безопасности корпоративной сети и цензуры в Интернете. Их также критикуют с точки зрения конфиденциальности, поскольку они отдают разрешение DNS в руки небольшого числа компаний, известных своей монетизацией пользовательского трафика и централизацией разрешения имен DNS, что обычно воспринимается как вредное для Интернета. ^[55]

Google является доминирующим поставщиком платформы Android , браузера Chrome и преобразователя DNS в сервисе 8.8.8.8. Будет ли этот сценарий случаем, когда одна корпоративная организация будет иметь всеобъемлющий контроль над всем пространством имен Интернета? Netflix уже представил приложение, которое использовало собственный механизм разрешения DNS, независимый от платформы, на которой приложение работало. Что, если бы приложение Facebook включало DoH? Что, если Apple от iOS использовала механизм разрешения DoH, чтобы обойти разрешение локального DNS и направить все DNS-запросы от платформ Apple к набору преобразователей имен, управляемых Apple?
— Конфиденциальность DNS и IETF

Регистрация доменного имени [ править ]

Право на использование доменного имени делегируется регистраторами доменных имен, аккредитованными Интернет-корпорацией по присвоению имен и номеров (ICANN) или другими организациями, такими как OpenNIC , которым поручено контролировать системы имен и номеров в Интернете. Помимо ICANN, каждый домен верхнего уровня (TLD) обслуживается и технически обслуживается административной организацией, управляющей реестром. Реестр . отвечает за работу базы данных имен в своей авторитетной зоне, хотя этот термин чаще всего используется для TLD Регистрант . — это лицо или организация, подавшие заявку на регистрацию домена ^[23]Реестр получает регистрационную информацию от каждого регистратора доменных имен , который уполномочен (аккредитован) присваивать имена в соответствующей зоне, и публикует информацию с использованием протокола WHOIS . С 2015 года возможность использования RDAP . рассматривается ^[56]

ICANN публикует полный список TLD, реестров TLD и регистраторов доменных имен. Информация о владельцах доменов, связанная с доменными именами, хранится в онлайн-базе данных, доступной через службу WHOIS. Для большинства из более чем 290 национальных доменов верхнего уровня (ccTLD) реестры доменов хранят информацию WHOIS (регистрант, серверы имен, даты истечения срока действия и т. д.). Например, DENIC (NIC Германии) содержит данные домена DE. Примерно с 2001 года большинство реестров родовых доменов верхнего уровня (gTLD) приняли так называемый подход к расширенному реестру, то есть хранение данных WHOIS в центральных реестрах, а не в базах данных регистраторов.

Для доменов верхнего уровня в COM и NET тонкого используется модель реестра. Реестр доменов (например, GoDaddy , BigRock и PDR , VeriSign и т. д. и т. п.) содержит основные данные WHOIS (т. е. регистратора и серверов имен и т. д.). С другой стороны, организации или зарегистрированные лица, использующие ORG, находятся в реестре общественных интересов исключительно .

Некоторые реестры доменных имен, часто называемые сетевыми информационными центрами (NIC), также выполняют функции регистраторов для конечных пользователей, а также предоставляют доступ к наборам данных WHOIS. Реестры доменов верхнего уровня, такие как домены COM, NET и ORG, используют модель реестр-регистратор, состоящую из множества регистраторов доменных имен. ^[57]При этом методе управления реестр управляет только базой данных доменных имен и отношениями с регистраторами. Регистранты (пользователи доменного имени) являются клиентами регистратора, в некоторых случаях посредством дополнительного субподряда реселлеров.

Документы RFC [ править ]

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

Стандарты [ править ]

RFC 1034 , Доменные имена — концепции и возможности
RFC 1035 , Доменные имена – реализация и спецификация
RFC 1123 , Требования к интернет-хостам — применение и поддержка
RFC 1995 , Дополнительная передача зоны в DNS
RFC 1996 , Механизм оперативного уведомления об изменениях зоны (DNS NOTIFY).
RFC 2136 , Динамические обновления в системе доменных имен (DNS UPDATE)
RFC 2181 , Разъяснения к спецификации DNS
RFC 2308 , Отрицательное кэширование DNS-запросов (DNS NCACHE)
RFC 2672 , Нетерминальное перенаправление DNS-имен
RFC 2845 , Аутентификация транзакции с секретным ключом для DNS (TSIG)
RFC 3225 , указывающий на поддержку DNSSEC со стороны резольвера.
RFC 3226 , DNSSEC и IPv6 A6, требования к размеру сообщения сервера/преобразователя
RFC 3596 , Расширения DNS для поддержки IP версии 6
RFC 3597 , Обработка неизвестных типов записей ресурсов DNS (RR)
RFC 4343 , Разъяснение нечувствительности к регистру системы доменных имен (DNS)
RFC 4592 , Роль подстановочных знаков в системе доменных имен.
RFC 4635 , Идентификаторы алгоритмов HMAC SHA TSIG
RFC 5001 , опция идентификатора сервера DNS-имен (NSID)
RFC 5011 , Автоматическое обновление якорей доверия безопасности DNS (DNSSEC)
RFC 5452 , Меры по повышению устойчивости DNS к поддельным ответам
RFC 5890 , Интернационализированные доменные имена для приложений (IDNA): определения и структура документации
RFC 5891 , Интернационализированные доменные имена в приложениях (IDNA): протокол
RFC 5892 , Кодовые точки Unicode и интернационализированные доменные имена для приложений (IDNA)
RFC 5893 , Скрипты с письмом справа налево для интернационализированных доменных имен для приложений (IDNA)
RFC 6891 , Механизмы расширения DNS (EDNS0)
RFC 7766 , Транспортировка DNS через TCP — требования к реализации

безопасности Предлагаемые стандарты

RFC 4033 , Введение в безопасность DNS и требования
RFC 4034 , Записи ресурсов для расширений безопасности DNS
RFC 4035 , Изменения протокола для расширений безопасности DNS
RFC 4509 , Использование SHA-256 в записях ресурсов подписывающего лица делегирования DNSSEC (DS)
RFC 4470 , минимально охватывающий записи NSEC и онлайн-подпись DNSSEC
RFC 5155 , DNS Security (DNSSEC) хешированное подтверждение существования с проверкой подлинности
RFC 5702 , Использование алгоритмов SHA-2 с RSA в DNSKEY и записях ресурсов RRSIG для DNSSEC
RFC 5910 , Сопоставление расширений безопасности системы доменных имен (DNS) для расширяемого протокола обеспечения (EPP)
RFC 5933 , Использование алгоритмов подписи ГОСТ в записях ресурсов DNSKEY и RRSIG для DNSSEC
RFC 7830 , Опция заполнения EDNS(0)
RFC 7858 , Спецификация DNS поверх безопасности транспортного уровня (TLS)
RFC 8310 , Профили использования DNS через TLS и DNS через DTLS
RFC 8484 , DNS-запросы через HTTPS (DoH)

Экспериментальные RFC [ править ]

RFC 1183 , Новые определения DNS RR

текущие Лучшие практики

RFC 2182 , Выбор и работа вторичных DNS-серверов (BCP 16)
RFC 2317 , Бесклассовое делегирование IN-ADDR.ARPA (BCP 20)
RFC 5625 , Рекомендации по реализации DNS-прокси (BCP 152)
RFC 6895 , Вопросы системы доменных имен (DNS) IANA (BCP 42)
RFC 7720 , Протокол службы корневых имен DNS и требования к развертыванию (BCP 40)

Информационные RFC [ править ]

Эти RFC носят рекомендательный характер, но могут предоставить полезную информацию, несмотря на то, что они не определяют ни стандарт, ни BCP. (РФК 1796)

RFC 1178 , Выбор имени для вашего компьютера (к вашему сведению 5)
RFC 1591 , Структура системы доменных имен и делегирование
RFC 1912 , Распространенные ошибки работы и конфигурации DNS
RFC 2100 , Именование хостов
RFC 3696 , Методы применения для проверки и преобразования имен
РФК 3833 . Анализ угроз системы доменных имен (DNS)
RFC 4892 , Требования к механизму идентификации экземпляра сервера имен
RFC 5894 , Интернационализированные доменные имена для приложений (IDNA): предыстория, объяснение и обоснование
RFC 5895 , Сопоставление символов для интернационализированных доменных имен в приложениях (IDNA), 2008 г.
RFC 7626 , Вопросы конфиденциальности DNS
RFC 7706 , Уменьшение времени доступа к корневым серверам за счет запуска одного из них по шлейфу
RFC 7816 , Минимизация имени DNS-запроса для улучшения конфиденциальности
RFC 8499 , Терминология DNS

Неизвестно [ править ]

Эти RFC имеют официальный статус «Неизвестно» , но из-за своего возраста не помечены как таковые.

RFC 920 , Требования к домену — указанные исходные домены верхнего уровня.
RFC 1032 , Руководство администратора домена
RFC 1033 , Руководство по эксплуатации администраторов домена
RFC 1101 , DNS-кодировки сетевых имен и других типов

См. также [ править ]

Ссылки [ править ]

^ Ву, Хао; Данг, Сянлэй; Ван, Лидун; Он, Лунтао (2016). «Метод на основе объединения информации для обнаружения и идентификации атак отравления кэша распределенной системы доменных имен» . Информационная безопасность ИЭПП . 10 (1): 37–44. doi : 10.1049/iet-ifs.2014.0386 . ISSN 1751-8717 . S2CID 45091791 .
^ RFC 781, Интернет-протокол - Спецификация протокола интернет-программы DARPA , Институт информационных наук, Дж. Постел (ред.), Интернет-сообщество (сентябрь 1981 г.)
^ Дж. Дилли, Б. Мэггс, Дж. Парих, Х. Прокоп, Р. Ситараман и Б. Вейль. «Глобально распределенная доставка контента, IEEE Internet Computing, сентябрь/октябрь 2002 г., стр. 50–58» (PDF) . Архивировано (PDF) из оригинала 17 апреля 2015 г.
^ Нигрен., Э.; Ситараман Р.К.; Сан, Дж. (2010). «Сеть Akamai: платформа для высокопроизводительных интернет-приложений» (PDF) . Обзор операционных систем ACM SIGOPS . 44 (3): 2–19. дои : 10.1145/1842733.1842736 . S2CID 207181702 . Архивировано (PDF) из оригинала 2 декабря 2010 г. Проверено 19 ноября 2012 г.
^ Перейти обратно: ^а ^б ^с ^д ^Это ^ж Мокапетрис, Пол (ноябрь 1987 г.). Доменные имена – реализация и спецификация . IETF . дои : 10.17487/RFC1035 . РФК 1035 .
^ Чампика Виджаятунга (февраль 2015 г.). «Обработка злоупотреблений DNS» (PDF) . АПНИК . Архивировано (PDF) из оригинала 22 декабря 2015 г. Проверено 18 декабря 2016 г.
^ Дж. Кленсин (февраль 2003 г.). Роль системы доменных имен (DNS) . Сетевая рабочая группа. дои : 10.17487/RFC3467 . РФК 3467 . Информационный.
^ Лю, Крикет; Альбиц, Пол (2006). DNS и BIND (5-е изд.). О'Рейли Медиа. п. 3. ISBN 978-0-596-10057-5 .
^ Эванс 2018 , с. 112.
^ Эванс 2018 , с. 113.
^ Анналы IEEE [3B2-9] man2011030074.3d 29.07.011 11:54 Страница 74
^ Перейти обратно: ^а ^б «Почему Сеть все еще работает на Рождество? Пол Мокапетрис - Зал славы Интернета» . www.internethalloffame.org . 23 июля 2012 г.
^ Перейти обратно: ^а ^б Эванс 2018 , с. 119.
^ Эванс 2018 , с. 120.
^ Эванс 2018 , с. 120–121.
^ «Элизабет Фейнлер» . Зал славы Интернета . Архивировано из оригинала 14 сентября 2018 года . Проверено 25 ноября 2018 г.
^ «Пол Мокапетрис | Зал славы Интернета» . www.internethalloffame.org . Проверено 12 февраля 2020 г.
^ Андрей Робачевский (26 ноября 2013 г.). «С 30-летием, DNS!» . Интернет-сообщество . Проверено 18 декабря 2015 г.
^ Элизабет Фейнлер, Анналы IEEE, 3B2-9 man2011030074.3d 29.07.011 11:54 Страница 74
^ Терри, Дуглас Б.; и другие. (12–15 июня 1984 г.). «Сервер доменных имен Интернета в Беркли» . Летняя конференция, Солт-Лейк-Сити, 1984 г.: Материалы . Группа пользователей программных средств Ассоциации USENIX. стр. 23–31.
^ Консорциум Интернет-систем. «История BIND» . История БИНД. Архивировано из оригинала 30 июня 2019 г. Проверено 4 апреля 2022 г.
^ Перейти обратно: ^а ^б ^с ^д ^Это Мокапетрис, Пол (ноябрь 1987 г.). Доменные имена — концепции и возможности домена . IETF . дои : 10.17487/RFC1034 . РФК 1034 .
^ Перейти обратно: ^а ^б Пол Хоффман; Эндрю Салливан; Казунори Фудзивара (декабрь 2015 г.). Терминология DNS . IETF . дои : 10.17487/RFC7719 . RFC 7719 . Проверено 18 декабря 2015 г.
^ Пол Мокапетрис (ноябрь 1987 г.). «Спецификации пространства имен и терминология» . Доменные имена — концепции и возможности домена . IETF . сек. 3.1. дои : 10.17487/RFC1034 . РФК 1034 . Проверено 17 декабря 2015 г.
^ Перейти обратно: ^а ^б Пол Мокапетрис (ноябрь 1987 г.). «Как база данных делится на зоны» . Доменные имена — концепции и возможности домена . IETF . сек. 4.2. дои : 10.17487/RFC1034 . РФК 1034 . Проверено 17 декабря 2015 г.
^ Линдси, Дэвид (2007). Международное законодательство о доменных именах: ICANN и UDRP . Издательство Блумсбери. п. 8. ISBN 978-1-84113-584-7 .
^ Д. Истлейк, 3-е место (январь 2006 г.). Пояснение о нечувствительности к регистру в системе доменных имен (DNS) . Сетевая рабочая группа. дои : 10.17487/RFC4343 . RFC 4343 . {{citation}}: CS1 maint: numeric names: authors list (link) Proposed Standard. Updated by RFC 5890. Updates RFC 1034 , 1035 и 2181 .
^ Перейти обратно: ^а ^б Дж. Кленсин (февраль 2004 г.). Приемы применения для проверки и преобразования имен . Сетевая рабочая группа. дои : 10.17487/RFC3696 . РФК 3696 . Информационный.
^ Фудзивара, Кадзунори; Салливан, Эндрю; Хоффман, Пол (2019). «Терминология DNS» . www.tools.ietf.org . дои : 10.17487/RFC8499 . Проверено 21 июня 2020 г.
^ Немет, Эви; Снайдер, Гарт; Хейн, Трент Р. (30 октября 2006 г.). Руководство по администрированию Linux . Аддисон-Уэсли Профессионал. ISBN 978-0-13-700275-7 .
^ Биссянде, Тегавенде Ф.; Си, Умару (09 октября 2017 г.). Электронная инфраструктура и электронные услуги для развивающихся стран: 8-я Международная конференция, AFRICOMM 2016, Уагадугу, Буркина-Фасо, 6-7 декабря 2016 г., Материалы . Спрингер. ISBN 978-3-319-66742-3 .
^ «ДНС-зона» . Цифровой гид IONOS . 27 января 2022 г. Проверено 31 марта 2022 г.
^ «Что такое распространение DNS?» . Цифровой гид IONOS . Проверено 22 апреля 2022 г.
^ «Провайдеры игнорируют DNS TTL?» . Слэшдот . 2005 . Проверено 7 апреля 2012 г.
^ Бен Андерсон (7 сентября 2011 г.). «Бен Андерсон: Почему кэширование DNS в веб-браузере может быть плохим» . Проверено 20 октября 2014 г.
^ «Как Internet Explorer использует кеш для записей хостов DNS» . Корпорация Майкрософт . 2004 . Проверено 25 июля 2010 г.
^ «Параметры системы доменных имен (DNS)» . ИАНА . DNS RCODE . Проверено 14 июня 2019 г.
^ Джеймс Ф. Куроуз и Кейт В. Росс, Компьютерные сети: нисходящий подход, 6-е изд. Эссекс, Англия: Pearson Educ. Лимитед, 2012 г.
^ RFC 5395, Вопросы IANA по системе доменных имен (DNS) , Д. Истлейк, 3-е (ноябрь 2008 г.), раздел 3
^ RFC 5395, Вопросы IANA по системе доменных имен (DNS) , Д. Истлейк, 3-е (ноябрь 2008 г.), стр. 11
^ Перейти обратно: ^а ^б RFC 4592 , Роль подстановочных знаков в системе доменных имен , Э. Льюис (июль 2006 г.)
^ С. Томсон; Ю. Рехтер; Дж. Баунд (апрель 1997 г.). П. Викси (ред.). Динамические обновления в системе доменных имен (DNS UPDATE) . Сетевая рабочая группа. дои : 10.17487/RFC2136 . РФК 2136 . Предлагаемый стандарт. Обновления RFC 1035. Updated by RFC 3007 , 4033 , 4034 и 4035 .
^ RFC 2671 , Механизмы расширения DNS (EDNS0) , П. Викси (август 1999 г.)
^ Чикор, Левенте; Дивакаран, Динил Мон (февраль 2021 г.). «Конфиденциальность DNS через HTTPS: реквием по мечте?» (PDF) . Национальный университет Сингапура. Мы выясняем, отличается ли DoH-трафик от зашифрованного веб-трафика. С этой целью мы обучаем модель машинного обучения классифицировать HTTPS-трафик как Web или DoH. Используя нашу модель идентификации DoH, мы показываем, что авторитарный интернет-провайдер может правильно идентифицировать ≈97,4% пакетов DoH, неправильно классифицируя только 1 из 10 000 веб-пакетов.
^ Уитема, Кристиан; Дикинсон, Сара; Мэнкин, Эллисон (май 2022 г.). DNS через выделенные соединения QUIC . Рабочая группа по интернет-инжинирингу. дои : 10.17487/RFC9250 . РФК 9250 .
^ Шмитт, Пол; Эдмундсон, Энн; Фимстер, Ник (2019). «Забывчивый DNS: практическая конфиденциальность DNS-запросов» (PDF) . Технологии повышения конфиденциальности . 2019 (2): 228–244. arXiv : 1806.00276 . дои : 10.2478/popets-2019-0028 . S2CID 44126163 . Архивировано (PDF) из оригинала 21 января 2022 г.
^ «Забывчивый DNS, развернутый Cloudflare и Apple» . 9 декабря 2020 г. Проверено 27 июля 2022 г.
^ Поли, Томми (2 сентября 2021 г.). «Забывчивый DNS через HTTPS» . IETF.
^ Маффет, Алек (февраль 2021 г.). « Нет порта 53, кто это?» Год DNS через HTTPS через Tor» (PDF) . Симпозиум по безопасности сетей и распределенных систем. Архивировано (PDF) из оригинала 21 марта 2021 г. DNS через HTTPS (DoH) устраняет многие, но не все риски, а его транспортный протокол (т. е. HTTPS) вызывает обеспокоенность по поводу конфиденциальности из-за (например) «куки-файлов». Сеть Tor существует для того, чтобы предоставить TCP-каналам некоторую свободу от отслеживания, наблюдения и блокировки. Таким образом: в сочетании с Tor, DoH и принципом «Тогда не делай этого» (DDTT) для смягчения отпечатков пальцев запросов я описываю DNS через HTTPS через Tor (DoHoT).
^ Улевич, Давид (6 декабря 2011 г.). «DNSCrypt – критично, фундаментально и своевременно» . Зонт Циско . Архивировано из оригинала 1 июля 2020 года.
^ «Спецификация анонимизированного DNSCrypt» . Гитхаб . DNSCrypt. Архивировано из оригинала 25 октября 2019 года.
^ «Забывчивый DoH · DNSCrypt/dnscrypt-proxy Wiki» . Гитхаб . Проект DNSCrypt . Проверено 28 июля 2022 г.
^ Герцберг, Амир; Шульман, Хая (01 января 2014 г.). «Модернизация безопасности сетевых протоколов: пример DNSSEC» . IEEE Интернет-вычисления . 18 (1): 66–71. дои : 10.1109/MIC.2014.14 . ISSN 1089-7801 . S2CID 12230888 .
^ APWG. «Глобальное исследование фишинга: использование доменных имен и тенденции в первом полугодии 2010 года». 15.10.2010. apwg.org. Архивировано 3 октября 2012 г. на Wayback Machine.
^ Перейти обратно: ^а ^б Хьюстон, Джефф (июль 2019 г.). «Конфиденциальность DNS и IETF» (PDF) . Журнал Интернет-протокола . Архивировано (PDF) из оригинала 30 сентября 2019 г.
^ «Рабочий профиль протокола доступа к регистрационным данным (RDAP) для реестров и регистраторов gTLD» . ИКАНН . 3 декабря 2015 г. Архивировано из оригинала 22 декабря 2015 г. Проверено 18 декабря 2015 г.
^ «Найти регистратора» . ВериСайн, Инк . Проверено 18 декабря 2015 г.

Источники [ править ]

Evans, Claire L. (2018). Broad Band: The Untold Story of the Women Who Made the Internet. New York: Portfolio/Penguin. ISBN 9780735211759.

External links[edit]

Vixie, Paul (2007-05-04). "DNS Complexity". ACM Queue. Archived from the original on 2023-03-29.
Zytrax.com, Open Source Guide – DNS for Rocket Scientists.
Internet Governance and the Domain Name System: Issues for Congress Congressional Research Service
Ball, James (28 February 2014). "Meet the seven people who hold the keys to worldwide internet security". The Guardian. Guardian News & Media Limited. Retrieved 28 February 2014.
Mess with DNS – site where you can do experiments with DNS.

[1] Ву, Хао; Данг, Сянлэй; Ван, Лидун; Он, Лунтао (2016). «Метод на основе объединения информации для обнаружения и идентификации атак отравления кэша распределенной системы доменных имен» . Информационная безопасность ИЭПП . 10 (1): 37–44. doi : 10.1049/iet-ifs.2014.0386 . ISSN 1751-8717 . S2CID 45091791 .

[rfc781-2] RFC 781, Интернет-протокол - Спецификация протокола интернет-программы DARPA , Институт информационных наук, Дж. Постел (ред.), Интернет-сообщество (сентябрь 1981 г.)

[3] Дж. Дилли, Б. Мэггс, Дж. Парих, Х. Прокоп, Р. Ситараман и Б. Вейль. «Глобально распределенная доставка контента, IEEE Internet Computing, сентябрь/октябрь 2002 г., стр. 50–58» (PDF) . Архивировано (PDF) из оригинала 17 апреля 2015 г.

[4] Нигрен., Э.; Ситараман Р.К.; Сан, Дж. (2010). «Сеть Akamai: платформа для высокопроизводительных интернет-приложений» (PDF) . Обзор операционных систем ACM SIGOPS . 44 (3): 2–19. дои : 10.1145/1842733.1842736 . S2CID 207181702 . Архивировано (PDF) из оригинала 2 декабря 2010 г. Проверено 19 ноября 2012 г.

[rfc1035-5] Перейти обратно: ^а ^б ^с ^д ^Это ^ж Мокапетрис, Пол (ноябрь 1987 г.). Доменные имена – реализация и спецификация . IETF . дои : 10.17487/RFC1035 . РФК 1035 .

[6] Чампика Виджаятунга (февраль 2015 г.). «Обработка злоупотреблений DNS» (PDF) . АПНИК . Архивировано (PDF) из оригинала 22 декабря 2015 г. Проверено 18 декабря 2016 г.

[rfc3467-7] Дж. Кленсин (февраль 2003 г.). Роль системы доменных имен (DNS) . Сетевая рабочая группа. дои : 10.17487/RFC3467 . РФК 3467 . Информационный.

[8] Лю, Крикет; Альбиц, Пол (2006). DNS и BIND (5-е изд.). О'Рейли Медиа. п. 3. ISBN 978-0-596-10057-5 .

[FOOTNOTEEvans2018112-9] Эванс 2018 , с. 112.

[FOOTNOTEEvans2018113-10] Эванс 2018 , с. 113.

[11] Анналы IEEE [3B2-9] man2011030074.3d 29.07.011 11:54 Страница 74

[internethalloffame.org-12] Перейти обратно: ^а ^б «Почему Сеть все еще работает на Рождество? Пол Мокапетрис - Зал славы Интернета» . www.internethalloffame.org . 23 июля 2012 г.

[FOOTNOTEEvans2018119-13] Перейти обратно: ^а ^б Эванс 2018 , с. 119.

[FOOTNOTEEvans2018120-14] Эванс 2018 , с. 120.

[FOOTNOTEEvans2018120–121-15] Эванс 2018 , с. 120–121.

[16] «Элизабет Фейнлер» . Зал славы Интернета . Архивировано из оригинала 14 сентября 2018 года . Проверено 25 ноября 2018 г.

[17] «Пол Мокапетрис | Зал славы Интернета» . www.internethalloffame.org . Проверено 12 февраля 2020 г.

[18] Андрей Робачевский (26 ноября 2013 г.). «С 30-летием, DNS!» . Интернет-сообщество . Проверено 18 декабря 2015 г.

[19] Элизабет Фейнлер, Анналы IEEE, 3B2-9 man2011030074.3d 29.07.011 11:54 Страница 74

[Terry_USENIX_2004-20] Терри, Дуглас Б.; и другие. (12–15 июня 1984 г.). «Сервер доменных имен Интернета в Беркли» . Летняя конференция, Солт-Лейк-Сити, 1984 г.: Материалы . Группа пользователей программных средств Ассоциации USENIX. стр. 23–31.

[BIND_Home_Page-21] Консорциум Интернет-систем. «История BIND» . История БИНД. Архивировано из оригинала 30 июня 2019 г. Проверено 4 апреля 2022 г.

[rfc1034-22] Перейти обратно: ^а ^б ^с ^д ^Это Мокапетрис, Пол (ноябрь 1987 г.). Доменные имена — концепции и возможности домена . IETF . дои : 10.17487/RFC1034 . РФК 1034 .

[rfc7719-23] Перейти обратно: ^а ^б Пол Хоффман; Эндрю Салливан; Казунори Фудзивара (декабрь 2015 г.). Терминология DNS . IETF . дои : 10.17487/RFC7719 . RFC 7719 . Проверено 18 декабря 2015 г.

[dnsterms-24] Пол Мокапетрис (ноябрь 1987 г.). «Спецификации пространства имен и терминология» . Доменные имена — концепции и возможности домена . IETF . сек. 3.1. дои : 10.17487/RFC1034 . РФК 1034 . Проверено 17 декабря 2015 г.

[dnsparts-25] Перейти обратно: ^а ^б Пол Мокапетрис (ноябрь 1987 г.). «Как база данных делится на зоны» . Доменные имена — концепции и возможности домена . IETF . сек. 4.2. дои : 10.17487/RFC1034 . РФК 1034 . Проверено 17 декабря 2015 г.

[26] Линдси, Дэвид (2007). Международное законодательство о доменных именах: ICANN и UDRP . Издательство Блумсбери. п. 8. ISBN 978-1-84113-584-7 .

[rfc4343-27] Д. Истлейк, 3-е место (январь 2006 г.). Пояснение о нечувствительности к регистру в системе доменных имен (DNS) . Сетевая рабочая группа. дои : 10.17487/RFC4343 . RFC 4343 . {{citation}}: CS1 maint: numeric names: authors list (link) Proposed Standard. Updated by RFC 5890. Updates RFC 1034 , 1035 и 2181 .

[rfc3696-28] Перейти обратно: ^а ^б Дж. Кленсин (февраль 2004 г.). Приемы применения для проверки и преобразования имен . Сетевая рабочая группа. дои : 10.17487/RFC3696 . РФК 3696 . Информационный.

[29] Фудзивара, Кадзунори; Салливан, Эндрю; Хоффман, Пол (2019). «Терминология DNS» . www.tools.ietf.org . дои : 10.17487/RFC8499 . Проверено 21 июня 2020 г.

[30] Немет, Эви; Снайдер, Гарт; Хейн, Трент Р. (30 октября 2006 г.). Руководство по администрированию Linux . Аддисон-Уэсли Профессионал. ISBN 978-0-13-700275-7 .

[31] Биссянде, Тегавенде Ф.; Си, Умару (09 октября 2017 г.). Электронная инфраструктура и электронные услуги для развивающихся стран: 8-я Международная конференция, AFRICOMM 2016, Уагадугу, Буркина-Фасо, 6-7 декабря 2016 г., Материалы . Спрингер. ISBN 978-3-319-66742-3 .

[32] «ДНС-зона» . Цифровой гид IONOS . 27 января 2022 г. Проверено 31 марта 2022 г.

[33] «Что такое распространение DNS?» . Цифровой гид IONOS . Проверено 22 апреля 2022 г.

[34] «Провайдеры игнорируют DNS TTL?» . Слэшдот . 2005 . Проверено 7 апреля 2012 г.

[35] Бен Андерсон (7 сентября 2011 г.). «Бен Андерсон: Почему кэширование DNS в веб-браузере может быть плохим» . Проверено 20 октября 2014 г.

[36] «Как Internet Explorer использует кеш для записей хостов DNS» . Корпорация Майкрософт . 2004 . Проверено 25 июля 2010 г.

[37] «Параметры системы доменных имен (DNS)» . ИАНА . DNS RCODE . Проверено 14 июня 2019 г.

[38] Джеймс Ф. Куроуз и Кейт В. Росс, Компьютерные сети: нисходящий подход, 6-е изд. Эссекс, Англия: Pearson Educ. Лимитед, 2012 г.

[39] RFC 5395, Вопросы IANA по системе доменных имен (DNS) , Д. Истлейк, 3-е (ноябрь 2008 г.), раздел 3

[40] RFC 5395, Вопросы IANA по системе доменных имен (DNS) , Д. Истлейк, 3-е (ноябрь 2008 г.), стр. 11

[rfc4592-41] Перейти обратно: ^а ^б RFC 4592 , Роль подстановочных знаков в системе доменных имен , Э. Льюис (июль 2006 г.)

[rfc2136-42] С. Томсон; Ю. Рехтер; Дж. Баунд (апрель 1997 г.). П. Викси (ред.). Динамические обновления в системе доменных имен (DNS UPDATE) . Сетевая рабочая группа. дои : 10.17487/RFC2136 . РФК 2136 . Предлагаемый стандарт. Обновления RFC 1035. Updated by RFC 3007 , 4033 , 4034 и 4035 .

[43] RFC 2671 , Механизмы расширения DNS (EDNS0) , П. Викси (август 1999 г.)

[44] Чикор, Левенте; Дивакаран, Динил Мон (февраль 2021 г.). «Конфиденциальность DNS через HTTPS: реквием по мечте?» (PDF) . Национальный университет Сингапура. Мы выясняем, отличается ли DoH-трафик от зашифрованного веб-трафика. С этой целью мы обучаем модель машинного обучения классифицировать HTTPS-трафик как Web или DoH. Используя нашу модель идентификации DoH, мы показываем, что авторитарный интернет-провайдер может правильно идентифицировать ≈97,4% пакетов DoH, неправильно классифицируя только 1 из 10 000 веб-пакетов.

[45] Уитема, Кристиан; Дикинсон, Сара; Мэнкин, Эллисон (май 2022 г.). DNS через выделенные соединения QUIC . Рабочая группа по интернет-инжинирингу. дои : 10.17487/RFC9250 . РФК 9250 .

[46] Шмитт, Пол; Эдмундсон, Энн; Фимстер, Ник (2019). «Забывчивый DNS: практическая конфиденциальность DNS-запросов» (PDF) . Технологии повышения конфиденциальности . 2019 (2): 228–244. arXiv : 1806.00276 . дои : 10.2478/popets-2019-0028 . S2CID 44126163 . Архивировано (PDF) из оригинала 21 января 2022 г.

[47] «Забывчивый DNS, развернутый Cloudflare и Apple» . 9 декабря 2020 г. Проверено 27 июля 2022 г.

[48] Поли, Томми (2 сентября 2021 г.). «Забывчивый DNS через HTTPS» . IETF.

[49] Маффет, Алек (февраль 2021 г.). « Нет порта 53, кто это?» Год DNS через HTTPS через Tor» (PDF) . Симпозиум по безопасности сетей и распределенных систем. Архивировано (PDF) из оригинала 21 марта 2021 г. DNS через HTTPS (DoH) устраняет многие, но не все риски, а его транспортный протокол (т. е. HTTPS) вызывает обеспокоенность по поводу конфиденциальности из-за (например) «куки-файлов». Сеть Tor существует для того, чтобы предоставить TCP-каналам некоторую свободу от отслеживания, наблюдения и блокировки. Таким образом: в сочетании с Tor, DoH и принципом «Тогда не делай этого» (DDTT) для смягчения отпечатков пальцев запросов я описываю DNS через HTTPS через Tor (DoHoT).

[50] Улевич, Давид (6 декабря 2011 г.). «DNSCrypt – критично, фундаментально и своевременно» . Зонт Циско . Архивировано из оригинала 1 июля 2020 года.

[Anonymized_DNSCrypt_specification-51] «Спецификация анонимизированного DNSCrypt» . Гитхаб . DNSCrypt. Архивировано из оригинала 25 октября 2019 года.

[ODoH_(2022)-52] «Забывчивый DoH · DNSCrypt/dnscrypt-proxy Wiki» . Гитхаб . Проект DNSCrypt . Проверено 28 июля 2022 г.

[53] Герцберг, Амир; Шульман, Хая (01 января 2014 г.). «Модернизация безопасности сетевых протоколов: пример DNSSEC» . IEEE Интернет-вычисления . 18 (1): 66–71. дои : 10.1109/MIC.2014.14 . ISSN 1089-7801 . S2CID 12230888 .

[54] APWG. «Глобальное исследование фишинга: использование доменных имен и тенденции в первом полугодии 2010 года». 15.10.2010. apwg.org. Архивировано 3 октября 2012 г. на Wayback Machine.

[Huston-2019-55] Перейти обратно: ^а ^б Хьюстон, Джефф (июль 2019 г.). «Конфиденциальность DNS и IETF» (PDF) . Журнал Интернет-протокола . Архивировано (PDF) из оригинала 30 сентября 2019 г.

[56] «Рабочий профиль протокола доступа к регистрационным данным (RDAP) для реестров и регистраторов gTLD» . ИКАНН . 3 декабря 2015 г. Архивировано из оригинала 22 декабря 2015 г. Проверено 18 декабря 2015 г.

[57] «Найти регистратора» . ВериСайн, Инк . Проверено 18 декабря 2015 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]