Длинный текст 4D взрывает протокол DNS!

Только подумайте, сколькими способами мы, люди, можем идентифицировать себя? Его можно идентифицировать по удостоверению личности, его можно идентифицировать по номеру карты социального страхования, его можно идентифицировать по водительским правам, и хотя у нас есть много способов идентификации, в определенных обстоятельствах один метод идентификации может быть более подходящим. чем другой. . Хосты в Интернете, как и люди, могут быть идентифицированы с помощью различных методов идентификации. Один из способов идентифицировать хост в Интернете — использовать его主机名(hostname),какwww.facebook.com, www.google.comЖдать. Но это то, как мы, люди, помним, маршрутизаторы этого не понимают, маршрутизаторы любят фиксированную длину, иерархические структуры.IP地址.

Если вы еще не понимаете IP, вы можете прочитать эту мою статьюуровень компьютерной сети

IP-адрес теперь выражается просто и представляет собой 4-байтовую структуру со строгой иерархической структурой. Например121.7.106.83IP-адрес, где можно использовать каждый байт.разделенный, показывая0 - 255десятичное число.

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

Полное имя DNSDomain Name System,DNS, представляющий собой слоистыйDNS 服务器（DNS server）Реализована распределенная база данных; это также протокол прикладного уровня, который позволяет хостам запрашивать распределенные базы данных. DNS-серверы обычно работаютBIND(Berkeley Internet Name Domain)Программное обеспечение для UNIX-машин. Протокол DNS работает наUDPВыше используйте порт 53.

Базовый обзор DNS

Подобно HTTP, FTP и SMTP, протокол DNS также является протоколом прикладного уровня.客户-服务器Этот режим работает между взаимодействующими конечными системами, и пакеты DNS передаются между взаимодействующими конечными системами через следующий сквозной транспортный протокол. Но DNS — это не приложение, которое имеет дело непосредственно с пользователями. DNS — это основная функция пользовательских приложений и другого программного обеспечения в Интернете.

DNS обычно не является автономным протоколом, он обычно используется другими протоколами прикладного уровня, включая HTTP, SMTP и FTP, для преобразования вводимых пользователем имен хостов в IP-адреса.

Ниже описан процесс разрешения DNS на примере, аналогично тому, что делает браузер после ввода URL-адреса.

вы вводите в браузереwww.someschool.edu/index.htmlЧто происходит, когда? Чтобы разрешить хосту пользователя отправлять сообщение HTTP-запроса на веб-серверwww.someschool.edu, пройдет следующие операции

Клиент, выполняющий приложение DNS на том же пользовательском хосте
Браузер извлекает имя хоста из указанного выше URL.www.someschool.edu, и передать это имя хоста клиенту приложения DNS
DNS-клиент отправляет запрос, содержащий имя хоста, на DNS-сервер.
DNS-клиент в конечном итоге получит ответное сообщение, содержащее IP-адрес целевого хоста.
Как только браузер получает IP-адрес целевого хоста, он может инициировать TCP-соединение с процессом HTTP-сервера на порту 80 этого IP-адреса.

Помимо предоставления IP-адреса для преобразования имени хоста, DNS также предоставляет следующие важные услуги.

主机别名(host aliasing), хост со сложным именем хоста может иметь один или несколько других псевдонимов, например, хост с именем relay1.west-coast.enterprise.com будет иметь как enterprise.com, так иwww.enterprise.comдва псевдонима хоста для , в данном случае relay1.west-coast.enterprise.com, также известный как规范主机名, а псевдонимы хостов легче запомнить, чем канонические имена хостов. Приложения могут вызывать DNS для получения канонического имени хоста, соответствующего псевдониму хоста и IP-адресу хоста.
邮件服务器别名(mail server aliasing), и аналогичным образом приложение электронной почты также может вызывать DNS для разрешения предоставленного имени хоста.
负载分配(load distribution), DNS также используется для распределения нагрузки между резервными серверами. загруженные сайты, такие какcnn.comОн избыточно распределяется по нескольким серверам, каждый из которых работает между разными конечными системами, каждая из которых имеет свой IP-адрес. Из-за этих избыточных веб-серверов набор IP-адресов связан с одним и тем же каноническим именем хоста. Набор этих IP-адресов хранится в базе данных DNS. Поскольку клиент каждый раз делает HTTP-запрос, циклический перебор DNS распределяет нагрузку между всеми этими резервными веб-серверами.

Обзор работы DNS

Предположим, какое-то приложение, работающее на хост-компьютере пользователя, например, веб-браузер или программа для чтения почты, должно преобразовывать имена хостов в IP-адреса. Эти приложения будут вызывать DNS-клиент и указывать имя хоста, которое необходимо перевести. После того, как DNS на пользовательском хосте получит его, он будет использовать UDP для отправки сообщения DNS-запроса в сеть через порт 53. Через некоторое время DNS на пользовательском хосте получит ответное сообщение DNS, соответствующее имени хоста. . Итак, с точки зрения хоста пользователя, DNS подобен черному ящику, вы не можете видеть, что происходит внутри него. Но на самом деле черный ящик, реализующий службу DNS, очень сложен: он состоит из большого количества DNS-серверов, распределенных по всему миру, и протокола прикладного уровня, который определяет, как DNS-сервер взаимодействует с хостом запроса.

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

单点故障(a single point of failure), если DNS-сервер выйдет из строя, то вся сеть будет парализована.
通信容量(traaffic volume), один DNS-сервер должен обрабатывать все DNS-запросы, количество которых может исчисляться миллионами или десятками миллионов.
远距离集中式数据库(distant centralized database), это невозможно для одного DNS-сервера邻近Для всех пользователей предполагается, что DNS-сервер в США не может использоваться для запроса в Австралии, где запрос запроса должен проходить по низкоскоростному и перегруженному каналу, что вызывает серьезную задержку.
维护(maintenance), затраты на обслуживание огромны, а также требуются частые обновления.

Следовательно, DNS не может быть спроектирован централизованно и вообще не имеет масштабируемости, поэтому он принимает分布式设计, поэтому характеристики этой конструкции следующие

Распределенная иерархическая база данных

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

Вообще говоря, существует три типа DNS-серверов:根 DNS 服务器,顶级域(Top-Level Domain, TLD) DNS 服务器и权威 DNS 服务器. Иерархическая модель этих серверов показана на следующем рисунке.

Предположим, теперь DNS-клиент хочет знатьwww.amazon.comIP-адрес, то как указанный выше сервер доменных имен разрешает его? Сначала клиент свяжется с одним из корневых серверов, который вернет домен верхнего уровня.comIP-адрес сервера TLD. Затем клиент связывается с одним из этих серверов TLD, который возвращает IP-адрес авторитетного сервера для amazon.com. Наконец, клиент связывается с одним из авторитетных серверов amazom.com, которыйwww.amazom.comВозвращает свой IP-адрес.

Иерархия DNS

Давайте теперь обсудим иерархию вышеуказанных серверов доменных имен.

根 DNS 服务器, существует более 400 корневых серверов имен по всему миру, эти корневые серверы имен управляются 13 различными организациями. Список и организацию корневых серверов имен можно найти по адресуroot-servers.org/, корневой сервер имен предоставляет IP-адрес сервера TLD.
顶级域 DNS 服务器, существует сервер TLD или кластер серверов для каждого из доменов верхнего уровня, таких как com, org, net, edu и gov, а также для всех национальных доменов uk, fr, ca и jp. Список всех доменов верхнего уровня см.tld-list.com/. Сервер TDL предоставляет IP-адрес полномочного DNS-сервера.
权威 DNS 服务器, которые имеют общедоступные узлы в Интернете, такие как веб-серверы и почтовые серверы, организации которых должны предоставлять доступные записи DNS, сопоставляющие имена этих узлов с IP-адресами. Эти DNS-записи размещаются на официальном DNS-сервере организации.

Шаги DNS-запроса

Ниже мы описываем шаги DNS-запроса, серию процессов от IP-адреса разрешения DNS до возврата DNS.

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

При нормальных обстоятельствах поиск DNS будет выполнять следующие шаги.

Пользователь вводит URL в браузереwww.example.comИ после нажатия Enter запрос отправляется в сеть и подхватывается распознавателем DNS.
Преобразователь DNS инициирует запрос к имени корневого домена, запрашивая возврат адреса доменного имени верхнего уровня.
Корневой DNS-сервер замечает префикс запрошенного адреса и возвращает com преобразователю DNS.顶级域名服务器(TLD)список IP-адресов.
Затем преобразователь DNS отправляет сообщение с запросом на сервер TLD.
После того, как сервер TLD получит запрос, он权威 DNS 服务器IP-адрес возвращен преобразователю DNS.
Наконец, преобразователь DNS отправляет запрос непосредственно полномочному DNS-серверу.
Авторитетный DNS-сервер возвращает IP-адрес преобразователю DNS
Преобразователь DNS ответит веб-браузеру IP-адресом.

Как только шаг поиска DNS возвращает IP-адрес example.com, браузер может запросить веб-страницу.

Весь процесс показан на рисунке ниже

DNS-преобразователь

Хост и программное обеспечение, которое делает DNS-запросы, называютсяDNS 解析器, используемые пользователями рабочие станции и персональные компьютеры принадлежат парсеру. Резолвер должен зарегистрировать хотя бы один IP-адрес сервера доменных имен. Преобразователь DNS — это первая остановка для поиска DNS и егоОтвечает за работу с клиентом, сделавшим первоначальный запрос. Преобразователь инициирует последовательность запросов, которые в конечном итоге преобразуют URL-адрес в необходимый IP-адрес.

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

Тип DNS-запроса

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

递归查询: в рекурсивном запросе DNS-клиент запрашивает, чтобы DNS-сервер (обычно рекурсивный преобразователь DNS) ответил клиенту с запрошенной записью ресурса или вернул сообщение об ошибке, если преобразователь не может найти запись.
迭代查询: в итеративном запросе, если запрошенный DNS-сервер не соответствует запрошенному имени, он вернет ссылку на DNS-сервер, который является полномочным для пространства имен более низкого уровня. Затем DNS-клиент запросит ссылающийся адрес. Этот процесс продолжается с другими DNS-серверами в цепочке запросов до тех пор, пока не произойдет ошибка или истечет время ожидания.
非递归查询: этот запрос обычно выполняется, когда клиент преобразователя DNS запрашивает у DNS-сервера запись, к которой у него есть доступ, либо потому, что он является авторитетным для этой записи, либо потому, что запись существует в его кэше. DNS-серверы обычно кэшируют записи DNS и могут возвращать кэшированные результаты непосредственно при поступлении запроса, чтобы предотвратить дальнейшее потребление полосы пропускания и нагрузку на вышестоящие серверы.

Кэш DNS

DNS 缓存(DNS caching)иногда называетсяDNS 解析器缓存,этоВременная база данных, поддерживаемая операционной системой, который содержитДоступ к записям последних веб-сайтов и других интернет-доменов. Другими словами, кэширование DNS — это просто технология, означающая, что компьютер кэширует загруженные ресурсы, чтобы обеспечить высокую скорость отклика, и на него можно напрямую и быстро ссылаться при повторном доступе. Так как же работает кэширование DNS?

Рабочий процесс кэширования DNS

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

Метод кэширования DNS

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

кеш браузера

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

существуетchromeВ браузере вы можете использовать chrome://net-internals/#dns для проверки состояния кеша DNS. Это основано на запросе под Windows. После ввода вышеуказанного URL-адреса на моем компьютере Mac я не могу просматривать DNS, толькоclear host cache, не знаю почему, может где причина?

Кэш ядра ОС

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

DNS-сообщение

Все DNS-серверы, совместно реализующие распределенную базу данных DNS, хранят资源记录(Resource Record, RR), RR обеспечивает сопоставление имен хостов с IP-адресами. Каждое ответное сообщение DNS будет содержать одну или несколько записей ресурсов. Записи RR используются для ответа на запросы клиентов.

Запись ресурса представляет собой 4-кортеж, содержащий следующие поля

(Name, Value, Type, TTL)

Существуют разные типы RR, ниже приведена сводная таблица различных типов RR.

Тип DNS-записи	объяснять
Запись	Записи узла IPv4 для сопоставления доменных имен с адресами IPv4
записи АААА	Записи узла IPv6 для сопоставления доменных имен с адресами IPv6
CNAME-запись	Записи псевдонимов, используемые для сопоставления псевдонимов доменных имен DNS.
MX-записи	Почтовый обменник для сопоставления доменных имен DNS с почтовыми серверами
PTR-записи	Указатель для обратного просмотра (разрешение IP-адреса для доменного имени)
SRV записи	Записи SRV для сопоставления доступных услуг.

DNS имеет два типа сообщений: одно сообщение запроса, другое ответное сообщение, и эти два сообщения имеют одинаковый формат, следующий формат сообщения DNS

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

заголовок сегмента

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

Идентификатор транзакции: Идентификатор транзакции занимает 2 байта. Это идентификатор DNS, также известный как标识符, для пакетов-запросов и пакетов-ответов значение этого поля одинаково, и идентификатор можно использовать, чтобы различать, на какой запрос отвечает пакет ответа DNS.
Флаги: Поле флагов занимает 2 байта. Полей флагов много, и они также более важны, все поля флагов перечислены ниже.

Значение каждого поля следующее

QR(Response): 1-битный QR определяет, является ли сообщение сообщением-запросом или сообщением-ответом.QR = 0 для сообщений-запросов и QR = 1 для сообщений-ответов.
OpCode: OpCode из 4 бит представляет собой код операции, где 0 представляет собой стандартный запрос, 1 представляет собой обратный запрос, а 2 представляет собой запрос состояния сервера.
AA(Authoritative): 1 бит AA обозначает ответ авторизации.Этот AA действителен только в ответных пакетах.Если значение равно 1, это указывает на то, что сервер имен является полномочным сервером, а значение 0 указывает на то, что он не является полномочным сервером. .
TC(Truncated): бит флага усечения, когда значение равно 1, это указывает, что ответ превысил 512 байтов и был усечен, и возвращаются только первые 512 байтов.
RD(Recursion Desired): это ожидаемое рекурсивное поле, которое устанавливается в запросе и возвращается в ответе. Этот флаг сообщает серверу имен, что этот запрос должен быть обработан способом, называемым рекурсивным запросом. Если этот бит равен 0, а запрошенный сервер имен не имеет авторитетного ответа, он вернет список других серверов имен, которые могут ответить на запрос. Такой подход называется итеративным запросом.
RA(Recursion Available): Доступно рекурсивное поле, это поле появляется только в ответном сообщении. Когда значение равно 1, это означает, что сервер поддерживает рекурсивные запросы.
zero: зарезервированное поле, его значение должно быть равно 0 во всех пакетах запросов и ответов.
AD: Это поле указывает, авторизовано ли сообщение.
CD: Это поле указывает, следует ли отключить проверки безопасности.

rcode（Reply code）: это поле является полем кода возврата, указывающим на статус ошибки ответа. Если значение равно 0, это означает, что ошибки нет, если значение равно 1, это означает, что формат сообщения неверен (ошибка формата), и сервер не может понять запрошенное сообщение, если значение равно 2, это означает, что что сервер доменных имен выходит из строя (сбой сервера), потому что сервер не может обработать запрос; когда значение равно 3, это означает, что имя неверно (ошибка имени), что имеет значение только для авторизованного сервера разрешения доменных имен , указывающее, что анализируемое доменное имя не существует, при значении 4 это означает, что тип запроса не существует Поддерживается (не реализовано), то есть сервер доменных имен не поддерживает тип запроса, при значении равно 5, это означает отказ, обычно сервер отказывается давать ответ из-за установленной политики, например, сервер не хочет давать ответ некоторым запрашивающим.

Я считаю, что читатели такие же, как и я. Просто смотреть на эти поля бессмысленно. Давайте посмотрим на конкретные пакеты DNS, перехватив пакеты.

Теперь мы можем посмотреть на конкретные DNS-пакеты,queryВидно, что это сообщение-запрос, и идентификатор этого сообщения0xcd28, который помечен следующим образом

QR = 0 Это запрос.
Затем идет четырехбайтовый OpCode со значением 0, указывающим, что это стандартный запрос.
Поскольку это запрос запроса, поле AA отсутствует.
Затем идет бит усеченного флага Truncated, что означает, что он не усечен.
RD = 1 сразу после этого, указывая на то, что желателен рекурсивный ответ.
В сообщении запроса нет поля RA.
Тогда есть зарезервированное поле ноль.
0 сразу после него указывает, что неаутентифицированные данные неприемлемы.
Поле rcode не имеет значения

Затем смотрим ответное сообщение

Видно, что бит флага также0xcd28, можно показать, что это ответ на вышеуказанный запрос запроса.

Мы не будем объяснять пакеты, которые уже были объяснены в запросе запроса, теперь мы объясним только содержимое, которого нет в пакете запроса.

Поле AA сразу после появления OpCode, и его значение равно 0, что указывает на то, что это не ответ от авторитетного DNS-сервера.
Последнее — это ответ поля rcode, когда значение равно 0, значит ошибки нет.

проблемная зона

Проблемная область обычно относится к части области проблемы запроса в формате сообщения. Этот раздел используется для отображения проблемы запроса запроса DNS, включая тип запроса и класс запроса.

Значение каждого поля в этом разделе следующее

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

Опять же, давайте использовать wireshark, чтобы посмотреть на проблемную область.

Как видите, это DNS-запрос к mobile-gtalk.l.google.com, тип запроса — A, значит, тип ответа тоже должен быть A.

Как показано на изображении выше, тип ответа — A, а значения для класса запроса обычно равны 1, 254 и 255, что означает класс Интернета, отсутствие класса и все классы, соответственно, это значения. нас интересует, другие значения обычно не используются для TCP/IP Интернет.

Раздел записи ресурсов

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

Поля в разделе записи ресурса имеют следующие значения

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

Часть записи ресурса появляется только в ответных пакетах DNS. Давайте посмотрим на конкретные примеры полей через ответное сообщение.

Значение доменного имени — mobile-gtalk.l.google.com , тип — A, класс — 1, время жизни — 5 секунд, длина данных — 4 байта, а адрес, представленный данные ресурса 63.233.189.188.

SOA-записи

В случае ответа авторитетного DNS-сервера в записи сохраняется важная информация о зоне, котораяSOAзаписывать. Все зоны DNS требуют, чтобы запись SOA соответствовала требованиям IETF. Записи SOA также важны для переноса зон.

Записи SOA имеют некоторые дополнительные поля в дополнение к полям ответа преобразователя DNS, как показано ниже.

Значение конкретных полей

PNAME: Основной сервер имен, который является именем основного сервера имен для зоны.
RNAME: почтовый ящик ответственного органа, RNAME представляет собой адрес электронной почты администратора, @ представляет собой ., то есть admin.example.com эквивалентенadmin@example.com.
序列号: А именно Серийный номер, серийный номер области является уникальным идентификатором области.
刷新间隔: Интервал обновления, время (в секундах), которое вторичный сервер должен ждать, прежде чем запросить у первичного сервера запись SOA, чтобы узнать, была ли она обновлена.
重试间隔: время, в течение которого сервер должен ждать, пока неотвечающий первичный сервер имен снова запросит обновление.
过期限制: если вторичный сервер не получает ответа от основного сервера в течение этого периода, он должен перестать отвечать на запросы для зоны.

Первичные серверы имен и серверы имен службы упомянуты выше, и отношения между ними следующие.

В этой части мы в основном объясняем записи RR типа A (IPv4) и SOA. Кроме того, существует много типов. Эта статья не будет подробно описана. Читатели и друзья могут прочитать "Протокол TCP/IP Volume 1" и официальный сайт клаудфлэрwoohoo.cloudflare.com/learning/computers…Зацените, стоит отметить, что cloudflare — очень хороший сайт для изучения сетевых протоколов.

DNS-безопасность

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

DNS-атаки в основном включают следующие методы

ПервыйDos 攻击, основной формой этой атаки является перегрузка важных DNS-серверов, таких как серверы TLD или корневые серверы имен, чтобы они не могли отвечать на запросы от авторитетных серверов, что делает DNS-запросы неэффективными.
Второй вид атакиDNS 欺骗, изменяя содержимое ресурса DNS, например, маскируясь под официальный DNS-сервер и отвечая на фальшивую запись ресурса, в результате чего хост подключается к неправильному IP-адресу при попытке подключения к другому компьютеру.
Третий вид атакиDNS 隧道, эта атака использует другие сетевые протоколы для туннелирования DNS-запросов и ответов. Злоумышленники могут использовать SSH, TCP или HTTP для передачи вредоносного ПО или украденной информации в DNS-запросы таким образом, что брандмауэр становится необнаружимым, что приводит к DNS-атаке.
Четвертая форма атакиDNS 劫持, при перехвате DNS злоумышленник перенаправляет запросы на другие серверы имен. Это можно сделать с помощью вредоносных программ или несанкционированной модификации DNS-сервера. Хотя результат аналогичен спуфингу DNS, это совершенно другая атака, поскольку она нацелена на записи DNS веб-сайта на серверах имен, а не на кэш распознавателя.
Глава 5 Форма атакиDDoS 攻击, также известная как распределенная атака типа «отказ в обслуживании», эта форма атаки эквивалентна обновленной версии атаки Dos.

Так как же защититься от DNS-атак?

Один из самых известных способов защиты от DNS-угроз — использованиеDNSSEC 协议.

DNSSEC

DNSSEC, также известный какDNS 安全扩展, DNSSEC проводит数字签名для защиты его эффективности и, таким образом, предотвращения атак. Это серия механизмов аутентификации безопасности DNS, предоставляемых IETF. DNSSEC не шифрует данные, а просто проверяет правильность адреса посещаемого вами сайта.

DNS-брандмауэр

Некоторые атаки проводятся против сервера, что требует появления брандмауэра DNS,DNS 防火墙это инструмент, который предоставляет множество услуг безопасности и производительности для DNS-серверов. Брандмауэр DNS находится между распознавателем DNS пользователя и авторитетным сервером имен для веб-сайта или службы, к которым они пытаются получить доступ. Брандмауэр обеспечивает限速访问, чтобы остановить злоумышленников, пытающихся залить сервер. Если сервер выходит из строя из-за атаки или по любой другой причине, брандмауэр DNS может поддерживать работоспособность сайта или службы оператора, обслуживая ответы DNS из кэша.

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

Подробнее об атаках и защите DNS — это тема сетевой безопасности, и в этой статье мы не будем вдаваться в подробности.

Суммировать

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

Это относительно исчерпывающая статья о вводном DNS. На написание этой статьи у меня ушло больше недели. После понимания этой статьи вы должны быть в состоянии ответить на большинство вопросов о DNS, и я думаю, что интервью прошло стабильно. .

Кроме того, добавьте мой WeChat becxuan, присоединяйтесь к группе ежедневных вопросов и делитесь одним вопросом для интервью каждый день.Для получения дополнительной информации, пожалуйста, обратитесь к моему Github,Будь лучшим лучшимJavaer

Я сам переписал шесть PDF-файлов. После того, как WeChat искал «Programmer cxuan» и следил за официальной учетной записью, я ответил cxuan в фоновом режиме и получил все PDF-файлы.Эти PDF-файлы следующие:

Шесть ссылок в формате PDF