Введение
Распространённость DNS (и слабого контроля над ним) обеспечивает злоумышленников элегантными и тонкими методами для установки соединений и обмена данными.
По мнению Института SANS, 100% вредоносных программ используют DNS на каждом этапе своей работы — от проникновения и заражения до хищения данных. Как отмечено выше, DNS применяется и для того, чтобы взаимодействовать с центрами управления тем или иным способом. Это удобно для масштабирования и засекречивания своей инфраструктуры. Вредоносные агенты могут доставляться посредством различных сетевых протоколов (HTTP, FTP, SMTP или других распространённых стандартов обмена данными), но все эти методы так или иначе используют внутри себя DNS.
Рисунок 1. Роль DNS в атаках
Системы сетевой безопасности, как правило, не контролируют DNS, потому что инженеры и администраторы обычно не рассматривают его как средство передачи вредоносных сообщений. При этом DNS может быть туннелем для отправки «полезной» нагрузки на скомпрометированный узел, а также трансляции команд от центра управления. В результате подобное туннелирование позволит обойти защиту организации. Из отчёта Cloud Mark за 2018 г. видно, что «почти 90 процентов фирм пострадали от своей инфраструктуры доменных имён, а почти половина из них обнаружила данные, выходящие из сети через DNS».
Debug logging
Prior to the introduction of DNS analytic logs, DNS debug logging was an available method to monitor DNS transactions. DNS debug logging is not the same as the enhanced DNS logging and diagnostics feature discussed in this topic. Debug logging is discussed here because it is also a tool that is available for DNS logging and diagnostics. See Using server debugging logging options for more information about DNS debug logging. The DNS debug log provides extremely detailed data about all DNS information that is sent and received by the DNS server, similar to the data that can be gathered using packet capture tools such as network monitor. Debug logging can affect overall server performance and also consumes disk space, therefore it is recommended to enable debug logging only temporarily when detailed DNS transaction information is needed.
Using ETW consumers
You can use ETW consumers such as tracelog.exe with DNS server audit and analytic events by specifying a GUID of {EB79061A-A566-4698-9119-3ED2807060E7}.
You can get tracelog.exe by downloading and installing the Windows Driver Kit (WDK). Tracelog.exe is included when you install the WDK, Visual Studio, and the Windows SDK for desktop apps. For information about downloading the kits, see Windows Hardware Downloads. For example, when you download and install Windows Driver Kit (WDK) 8 and accept the default installation path, tracelog.exe is available at C:\Program Files (x86)\Windows Kits\8.0\Tools\x64\tracelog.exe.
For more information about using tracelog.exe, see Tracelog Command Syntax. The following examples demonstrate how to use tracelog.exe with DNS audit and analytic event logs:
The following command will enable both analytical and audit logging:
While the trace is active, all analytical and audit events will be recorded in the C:\analytic_audit.etl file that was specified on the command line. You can stop tracing by issuing a stop command:
After stopping the trace, you can view the .etl file in Event Viewer by clicking Action and then clicking Open Saved Log. See the following example.
The following example enables just the analytical channel and matches only the keywords to 0x7FFFF:
A logging level of 5 is used in the previous examples. The following logging levels are available:
Logging level |
Description |
---|---|
0 (None) |
Logging OFF |
1 (Critical) |
Only critical events are logged, for example process exit or termination. If no logging level is given by the user this level is used by default. |
2 (Error) |
Only severe error events are logged, for example failures to complete a required task. |
3 (Warning) |
Errors that can cause a service issue, but are acceptable or recoverable, for example the first attempt to contact a forwarder has failed. |
4 (Informational) |
Very high-level events are recorded in the event log. These might include one message for each major task performed by the service. Use this setting to begin an investigation when the location of the problem is in doubt, for example a scavenger thread was started. |
5 (Verbose) |
All events are logged. This provides a complete log of the operation of the service. Use this level when the problem is traced to a particular category or a small set of categories. |
Monitoring DNS Events in Event Viewer
Even though the DNS management console contains a copy of the DNS event log, you can also use Event Viewer to view information on DNS events. Event Viewer stores events that are logged in a system log, application log, and security log. You can access Event Viewer from the Administrative Tools folder. A Windows Server 2003 computer running as a DNS server has an additional log displayed in Event Viewer, called the DNS Server log. This log contains errors and any important events that are reported by the DNS server.
A few of the more common DNS events are:
-
Event ID 2: Indicates that the DNS server has started.
-
Event ID 3: Indicates that the DNS server has shut down.
-
Event ID 414: Indicates that the DNS server has no primary DNS suffix specified.
-
Event ID 708: Indicates that because the DNS server found no primary or secondary zone type, it will run as a caching-only DNS server.
Он-лайн проверка записей для домена
Он-лайн проверка DNS записей имеет преимущество в том, что вы можете сделать ее с любого устройства с браузеров и доступом в Интернет.
Проверка записей DNS с помощью Набора инструментов администратора от Google
Набор инструментов для администратора от Google содержит утилиту Dig, с помощью которой можно проверить все интересующие вас записи для домена.
Особенность данного сервиса в том, что проверка идет только через DNS серверы Google.
Он-лайн проверка DNS записей от регистратора REG.RU
Регистратор REG.RU предлагает свой сервис DIG для просмотра записей для домена.
У этого сервиса в отличии от Google есть возможность выбрать DNS сервер, чтобы посмотреть записи для домена.
Как проверить NS записи на всех DNS серверов сразу
Если вы хотите проверить записи для домена на всех (на большинстве популярных) DNS серверах, то можно воспользоваться сайтом https://www.digwebinterface.com/. Который грубо говоря представляет собой WEB оболочку для утилиты DIG.
Очень удобно прослеживать как ваши изменения для доменных записей реплицируются по DNS серверам мира.
Дополнительные сервисы для проверки
Я привел только самые удобные с моей стороны сервисы по проверки NS записей для доменного имени. Но есть и другие:
- https://2ip.ru/dig/
- https://dnschecker.org/
Возможно вам они понравятся даже больше.
Траблшутинг сервера-коллектора логов
Очень часто тут бывают ошибки 0x138C, как ее решать я описал выше.
Еще если вы не дали права, то получите «Access is denied».
Еще если вы выбрали слишком много событий, то можете увидеть ошибку:
Error – Last retry time: 2022-08-28 16:43:18. Code (0×7A): The data area passed to a system call is too small. Next retry time
Если у вас есть такие крупные продукты, как SharePoint, MS Exchange, MS CRM, то получая с них события, вы можете видеть ошибку ID 6398:
The description for Event ID 6398 from source A cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
Как я вам выше показал в реестре Windows каждый журнал описан в своей ветке и за него отвечает определенная DLL библиотека, если такого источника не будет на вашем коллекторе, то и могут возникать подобного рода ошибки. Для крупных приложений очень сложно произвести перенос в другое место, так как очень много источников, кто туда пишет. Поэтому PowerShell нам в помощью.
На просторах интернета есть добрые люди, кто столкнулся с такой задачей и ее прекрасно выполнил, и самое прекрасное, что человек поделился решением со всем интернетом.
https://github.com/sanglyb/ps-copy-log-source если вдруг по какой-то причине скриптов не будет в доступе, то можете скачать их тут
Тут два скрипта:
- export-log — Для экспорта данных с серверов откуда собираем данные
- import-log — Для импорта на сервере-коллекторе недостающих данных
Алгоритм такой, копируем скрипт export-log на сервер со специфическим ПО, у меня это будет Dynamic CRM. Запустите PowerShell и перейдите в расположение вашего скрипта, выберите его и добавьте ключ, являющийся частью источника событий, например crm.
.\export-log.ps1 crm
Данный скрипт создаст папку с названием ключа, далее просканирует все журналы событий, если найдет среди них похожий на crm, то сделает их дамп и создаст текстовый файл со списком сдампленных разделов.
Вот еще пример с Kaspersky.
Теперь идем на сервер коллектор и копируем туда созданную ранее папку. После чего открываем PowerShell так же в режиме администратора и импортируем все, что до этого получили.
.\import-log crm
В скрипте изначально задан каталог C:\CustomEvents, так что создайте его заранее иначе будете получать ошибку. После этого все логи будут корректно отображаться.
Еще из проблем может быть недоступность порта 5985, который должна слушать служба winrm. Проверяем порт, как я рассказывал ранее. Может получиться так, что какая-то из служб может его занять, как в случае с 1С или IIS.
Посмотреть кто слушает и что netstat -ant, далее netsh http show iplisten
И удаляем:
netsh http delete iplisten ipaddress=ip
Серверы DNS
Работу DNS обеспечивают множество географически распределенных программных серверов, выстроенных в иерархическую (древовидную) структуру.
Система работает примерно так. Браузер или иная программа, взаимодействующая с Интернетом, отправляет запрос к «ближайшему» DNS-серверу, чтобы он по доменному имени нашел IP-адрес нужного узла. Если этот DNS-сервер «знает» адрес, то возвращает его в качестве ответа на запрос. Если же DNS-сервер не может найти адрес в своей базе данных, то отправляет запрос на вышестоящий по иерархии сервер либо на корневой. Вышестоящий сервер рассматривает запрос и поступает аналогичным образом: либо находит у себя и отправляет в качестве ответа IP-адрес искомого узла, либо передает запрос на корневой DNS-сервер, который начинает поиск на DNS-серверах, нижестоящих в иерархии доменов. Если IP-адрес удается найти, то он передается по цепочке тому DNS-серверу, с которого начался поиск, и тот отправляет ответ программе, которая сформулировала первоначальный запрос. Если поиск оказывается неудачным, то в программу возвращается сообщение об ошибке.
Поскольку программы очень часто по многу раз обращаются к одним и тем же доменам, их адреса хранятся поблизости — в файле hosts, локальном файле настроек DNS. При отсутствии нужного адреса обращение передается на стоящий внутри сети локальный DNS-сервер, где производится поиск адреса его в кэш-памяти, затем на локальный DNS-сервер интернет-провайдера, и так далее.
Аналогичным образом решается задача обратного поиска, когда по IP-адресу узла Интернета производится поиск его доменного имени. Такой поиск используется, в частности, в системах электронной почты.
Еще один важный вариант запроса — на добавление или изменение информации, содержащейся в DNS. Например, чтобы сайт с новым доменным именем (что-то вроде newservername.com) заработал, необходимо зарегистрировать его, сделать необходимые настройки и указать IP-адреса DNS-серверов, которые «знают», где находится новый сайт. Чтобы информация о новом доменном имени стала известна всему Интернету и чтобы новый сайт заработал, потребуется некоторое время — обычно 24 часа
Очень часто владельцы сайтов предпочитают не держать DNS-серверы у себя, а размещать их на сторонних хостинговых площадках — это позволяет повысить доступность сайтов. Чтобы свести риски к минимуму, владельцы сайтов пользуются услугами нескольких хостинг-провайдеров: если вдруг DNS-сервер на одной из площадок окажется недоступен, путь к сайту «укажут» DNS-серверы, расположенные на других площадках.
Отметим, что более продвинутые провайдеры услуг хостинга DNS-серверов, такие как StormWall, помимо собственно хостинга, предоставляют также сервисы защиты DNS от атак.
Зачем нужна технология DNS и как она работает
DNS — фундаментальная технология современной интернет-среды, которая отвечает за хранение и обработку информации о доменных адресах. Инструмент используется для преобразования доменных имен в IP-адреса в момент отправки пользователем запроса на сервер. IP-адрес — уникальный числовой идентификатор устройства. Он позволяет узнать, откуда загружается страница нужного сайта. Получается, технология DNS служит своеобразной «телефонной книгой», в которой хранится база доменных имен и их адресов.
Работу DNS-технологии в качестве этой самой «телефонной книги» обеспечивает DNS-сервер— оборудование или программное обеспечение, с помощью которого предоставляется доступ к системе доменных имен, хранятся данные о соответствии конкретного IP-адреса соответствующему домену, а также осуществляется кэширование информации в виде IP-адреса и соответствующего ему домена других DNS-серверов.
Система доменных имен работает не в виртуальном пространстве, а на определенных физических устройствах. Все данные о доменах хранятся в формате записей на компьютерах, оснащенных соответствующим программным обеспечением.
Ниже список самых популярных и общедоступных DNS-серверов (актуально на октябрь 2021):
- Google: 8.8. 8.8 & 8.8. 4.4.
- Quad9: 9.9. 9.9 & 149.112. 112.112.
- OpenDNS: 208.67. 222.222 & 208.67. 220.220.
- Cloudflare: 1.1. 1.1 & 1.0. 0.1.
- CleanBrowsing: 185.228. 168.9 & 185.228. 169.9.
- Alternate DNS: 76.76. 19.19 & 76.223. 122.150.
- AdGuard DNS: 94.140. 14.14 & 94.140.
Схема работы DNS-технологии
Пользователь вводит в адресную строку браузера доменное имя, а преобразователь доменных имен обращается к DNS-серверу. После получения IP-адреса сервер передает его браузеру пользователя.
Принцип работы DNS-технологии
Затем браузер делает запрос на сервер по этому IP-адресу и после получения ответа отображает страницу ресурса.
Выделим основные характеристики DNS-технологии:
- Хранение и управление данными распределенного характера. То есть отдельный DNS-сервер хранит только информацию по делегированным ему доменам.
-
Кэширование данных.При помощи кэширования ускоряется загрузка нужной информации с сервера. Ведь при обращении к любому ресурсу (даже при запросе внутренних страниц) серверы проверяют связь домена и IP-адреса. Но если запрашиваемый ресурс расположен, допустим, в другой точке мира, то скорость его загрузки может быть довольно медленной. Например, пользователь регулярно делает запросы на ресурс, который находится в другом государстве. Расположенный ближе всего к пользователю DNS-сервер кэширует данные о ресурсе и при следующим запросе выдает их клиенту максимально быстро. Источником кэширования, из которого поступают данные о сайте, являются первичные и вторичные DNS-серверы.
Для уменьшения уровня нагрузки DNS-сервер может хранить некоторое время определенное количество информации о других, не делегированных ему доменах. - Резервирование. Несколько изолированных логически и физически DNS-серверов хранят и обрабатывают информацию об одних и тех же узлах. Благодаря такому подходу обеспечивается доступность информации даже при сбое одного или нескольких серверов.
- Иерархическая структура. База доменных имен организована по принципу иерархии: корневой домен расположен на верхнем уровне, к которому примыкают домены первого уровня, к ним присоединяются домены второго уровня и т.д.
Как работают DNS-серверы:
- Пользователь вводит запрос в строке браузера. Тот в свою очередь перенаправляет его DNS-серверу, который ищет совпадения между доменным именем и IP. При обнаружении совпадений браузер делает запрос по IP-адресу сервера и получает в ответ нужную информацию, после чего браузер отображает ее. Если совпадения не обнаружены, тогда запрос перенаправляется корневому серверу.
- Корневой сервер снова перенаправляет запрос серверу первого уровня, а тот отправляет запрос серверу второго уровня. Процесс продолжается до тех пор, пока совпадение не будет найдено.
- Как только IP-адрес найден, браузер направляет запрос серверу, получает ответ и отображает полученную информацию.
Иногда DNS-серверы обрабатывают обратный запрос: когда пользователь хочет узнать доменное имя сайта по его IP-адресу. На сегодняшний день функционирует более десяти корневых серверов, которые расположены в разных точках мира.
Серверы DNS
Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.
Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю ), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.
Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).
Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.
Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.
Что запомнить
- DNS — это проводник в интернете. Он помогает браузерам находить адреса сайтов и успешно подключаться к ним.
- DNS состоит из двух частей: протокола и серверов. Протокол отвечает за передачу данных и поиск IP-адресов сайтов, а серверы хранят всю информацию о них.
- На самих серверах данные хранятся в упорядоченном виде. Там есть разные виды записей, которые говорят о том, что это за сайт, чтобы сделать поиск удобнее.
- Всего в мире существует 13 главных серверов, на которых располагается вся информация об интернете. Но, чтобы не потерять эти данные, серверы скопировали и разместили в разных странах — и всего их 123 штуки.
Installing and enabling DNS diagnostic logging
Perform the following procedures to install and enable DNS diagnostic logging on Windows Server 2012 R2. To install DNS diagnostic logging, the computer must be running the DNS Server role service.
If the DNS server is running Windows Server 2016 Technical Preview or later, diagnostic logging is already installed and you can skip the first procedure, performing only the steps in To enable DNS diagnostic logging below.
Membership in the Administrators group, or equivalent, is the minimum required to complete these procedures. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (https://go.microsoft.com/fwlink/?LinkId=83477).
To install DNS diagnostic logging
-
If the DNS server is running Windows Server 2012 R2, download the hotfix from https://support.microsoft.com/kb/2956577.
-
Double-click the self-extracting file, for example 475151_intl_x64_zip.exe.
-
In the Microsoft Self-Extractor dialog box, click Continue.
-
Type a location where you want to save the extracted files, for example C:\hotfix. If the directory does not yet exist, you will be asked if you wish to create it. Click Yes and confirm that All files were successfully unzipped is displayed, then click Ok.
-
In the location where files were unzipped, double-click the Windows Update file, for example Windows8.1-KB2956577-v2-x64.msu.
-
The Windows Update Standalone Installer will verify that the computer meets requirements to install the update. These requirements include some prerequisite updates. When verification is complete, click Yes when asked if you wish to install the Hotfix for Windows (KB2956577).
-
If recently downloaded updates have not yet been installed, you might need to restart the computer before the current hotfix can be installed. If this is required, you must restart the computer first and then run the Windows8.1-KB2956577-v2-x64.msu a second time after the computer has completed installing necessary updates. The Windows Update Standalone Installer will notify you that installation of the hotfix is not yet complete. If this happens, and you are prompted to restart the computer, click Restart Now.
-
If the computer is ready to install the update when you run the hotfix, installation will complete and you must restart the computer for the update to take effect. If Installation complete is displayed, click Restart Now for the update to take effect.
You can confirm that the hotfix was successfully installed by viewing installed updates in the Programs and Features control panel. If the update is successfully installed, Hotfix for Microsoft Windows (KB2956577) will be displayed. You can also verify installation of the hotfix by typing wmic qfe | find «KB2956577» at an elevated command prompt. The URL and date of installation for the hotfix will be displayed if it was successfully installed.
To enable DNS diagnostic logging
-
Type eventvwr.msc at an elevated command prompt and press ENTER to open Event Viewer.
-
In Event Viewer, navigate to Applications and Services Logs\Microsoft\Windows\DNS-Server.
-
Right-click DNS-Server, point to View, and then click Show Analytic and Debug Logs. The Analytical log will be displayed.
-
Right-click Analytical and then click Properties.
-
Under When maximum event log size is reached, choose Do not overwrite events (Clear logs manually), select the Enable logging checkbox, and click OK when you are asked if you want to enable this log. See the following example.
-
Click OK again to enable the DNS Server Analytic event log.
By default, analytic logs are written to the file: %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-DNSServer%4Analytical.etl.
See the following sections for details about events that are displayed in the DNS server audit and analytic event logs.
Проверка регистрации записи ресурса
Конечный контроллер домена использует запись ресурса DNS-псевдонима (CNAME) для указания партнера по репликации исходного контроллера домена. хотя контроллеры домена, работающие Windows server (начиная с Windows server 2003 с пакетом обновления 1 (sp1)), могут обнаружить исходные партнеры репликации с помощью полных доменных имен или, если это не удается, ожидается, что NetBIOS-намессе запись ресурса псевдонима (CNAME) будет проверяться на предмет правильной работы DNS.
Для проверки регистрации записей ресурсов, включая регистрацию записи ресурса псевдонима (CNAME), можно использовать следующую процедуру.
To verify resource record registration
- Откройте командную строку как администратор. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск. В поле Начать поиск введите Командная строка.
- Вверху меню Пуск щелкните правой кнопкой мыши элемент Командная строка и выберите пункт Запуск от имени администратора. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие — то, которое требуется, и нажмите кнопку Продолжить. С помощью средства Dcdiag можно проверить регистрацию всех записей ресурсов, необходимых для расположения контроллера домена, выполнив команду.
Эта команда проверяет регистрацию следующих записей ресурсов в DNS:
- псевдоним (CNAME): запись ресурса на основе глобального уникального идентификатора (GUID), которая находит партнера репликации.
- узел (A): запись ресурса узла, которая содержит IP-адрес контроллера домена.
- Записи ресурсов LDAP SRV: службы (SRV), которые находят LDAP-серверы.
- GC SRV: записи ресурсов службы (SRV), которые находят серверы глобального каталога
- PDC SRV: записи ресурсов службы (SRV), которые находят хозяева операций эмулятора основного контроллера домена.
Для проверки регистрации записи ресурса псевдонима (CNAME) можно использовать следующую процедуру.
Проверка регистрации записи ресурса псевдонима (CNAME)
- Откройте оснастку DNS. Чтобы открыть службу DNS, нажмите кнопку Пуск. В окне начать поиск введите днсмгмт. msc и нажмите клавишу ВВОД. Если откроется диалоговое окно Контроль учетных записей пользователей, убедитесь, что оно отображает нужное действие, и нажмите кнопку продолжить.
- Используйте оснастку DNS, чтобы выбрать любой контроллер домена, на котором работает служба DNS-сервера, где на сервере размещается зона DNS с тем же именем, что и домен Active Directory контроллера домена.
- В дереве консоли щелкните зону с именем _msdcs. Dns_Domain_Name.
- В области сведений убедитесь, что имеются следующие записи ресурсов: запись ресурса псевдонима (CNAME) с именем Dsa_Guid. _msdcs. < Dns_Domain_Name > и соответствующую запись ресурса узла (a) для имени DNS-сервера.
Если запись ресурса псевдонима (CNAME) не зарегистрирована, убедитесь, что динамическое обновление работает правильно. Используйте тест в следующем разделе, чтобы проверить динамическое обновление.
Структура доменного имени
Вместо обычных имен компьютеров, которые состоят из одного слова в системе DNS используются доменные имена. Имя компьютера состоит из нескольких частей, которые отделены друг от друга точками. Например, веб-сервер сайта о Мобильной связи и Технологиях имеет следующие имя www.zvondozvon.ru. Имя состоит из следующих частей ru это домен верхнего уровня, следующий домен отделён от него точкой zvondozvon домен второго уровня, и последний компонент www это имя компьютера в домене второго уровня.
Корневой домен
Важным элементом доменного имени, которое обычно не пишут, является корневой домен, он указывается точкой в конце. Если вы не укажете точку, то ничего страшного не произойдет, она подразумевается в конце каждого доменного имени.
Дерево доменных имен
Доменные имена образуют дерево. Корнем дерева является корневой домен, который представлен точкой. Затем идут домены верхнего уровня, которые бывают трех типов:
- Домены для различных типов организаций, которые используются, как правило внутри США (org, com, net). Домен org для некоммерческих организаций, com для коммерческих организаций, net для организации связанных с компьютерными сетями, есть также и другие домены.
- Тип доменов верхнего уровня, домены для стран. Каждая страна имеет свой домен. Домен Россия ru, домен Великобритании uk, и относительно недавно появились новые типы доменов верхнего уровня в которых можно использовать не только символы английского алфавита. Для России это домен рф.
- Затем идут домены второго уровня, например cisco.com, yandex.ru или яндекс.рф русскими буквами.
- На третьем уровне могут находиться, как домены следующего уровня их называют поддомены или адреса компьютера в домене второго уровня. Например, в домене yandex.ru есть компьютеры с адресами www.yandex.ru веб-сервер компании yandex, maps.yandex.ru сервер яндекс карт, такси.yandex.ru сервер яндекс такси и большое количество других серверов.
Доменная зона
Важным понятием в системе DNS является доменная зона. Это запись адресов всех компьютеров и всех поддоменов в некотором домене.
Корневая доменная зона содержит записи всех поддоменов первого уровня (org com net ru uk рф). Зона ru содержит записи всех доменов второго уровня (yandex urfu), зона urfu.ru записи всех поддоменов и всех компьютеров в домене urfu, и вот здесь еще показаны две отдельные зоны для разных институтов urfu, институт естественных наук (ins) и институт математики и компьютерных наук (imkn). Эти зоны содержат DNS-записи, о компьютерах соответствующих институтов.
Доменная зона является некоторым аналогом файла itc/hosts только в ней содержится не вся информация об именах компьютерах в сети, а некоторый ее фрагмент. Доменные зоны распределены по серверам DNS. Одну и ту же доменную зону может обслуживать несколько серверов DNS.
Например, корневую зону обслуживают больше всего серверов, так как к ним больше всего запросов. Все корневые серверы DNS содержат одинаковые записи. Зону ru также обслуживает несколько серверов DNS, у которых одна и та же база данных записи и доменов второго уровня.
Необязательно иметь выделенные DNS сервер для каждой доменной зоны, например DNS-сервер urfu может обслуживать зоны urfu.ru и ins.urfu.ru, а институт математики и компьютерных наук может иметь свой выделенный DNS сервер, который будет обслуживать зону imkn.urfu.ru.
Важным понятием в системе DNS является делегирование. Например DNS-сервер urfu отвечает за зону urfu.ru, но только часть информации об этой зоне хранится непосредственно на этом сервере, то что относится к urfu.ru и ins.urfu.ru. А для зоны imkn.urfu.ru создан отдельный сервер, таким образом сервер urfu.ru делегирует полномочия управления под доменом imkn.urfu.ru другому серверу. Чтобы было возможно делегирование на DNS сервере urfu.ru делаются соответствующие конфигурационные записи, которые указывают на DNS-сервер ответственный за зон, в нашем случае imkn.urfu.ru.
Инфраструктура DNS
Инфраструктура системы доменных имен состоит из следующих компонентов.
Дерево серверов DNS, которые мы рассмотрели выше, клиент DNS это как правило наш компьютер, и сервер разрешения имен DNS по-английски его называют DNS resolver, он получает запрос от клиента и выполняет поиск необходимого ip-адреса в дереве доменных имен.
Типы DNS-записей
Функции ресурсных записей – это не только хранение, передача информации и привязка к IP адресу. Они также помогают настроить обработку запросов, перенаправляют их на другие серверы. Вот несколько наиболее важных типов DNS-записей:
- A – адресная запись, которая отвечает за привязку доменного имени к определенному IP-адресу по протоколу IPv4.
- AAAA – аналогична предыдущей, только действительна на основе интернет-протокола IPv6.
- CNAME – данный тип записи указывает на каноническое имя для псевдонима. С ее помощью к одному поддомену привязываются все ресурсные записи домена первого уровня.
- DKIM-подпись – подтверждает подлинность отправителя электронного письма. Именно эта ресурсная запись добавляет в сообщение цифровую подпись. Тем самым снижается вероятность попадания письма в папку «Спам».
- MX – регистрирует почтовые серверы, используя при этом протокол SMTP. Отвечает за доставку электронного письма на указанный сервер.
- NS – указывает на DNS-серверы, которые обслуживают домен. Чуть ли не одна из самых важных записей, без которой функционирование домена дало бы сбой.
- PTR – действует обратно записям A и AAAA, то есть показывает соответствие IP-адреса и доменного имени. Многие почтовые серверы во время фильтрации писем проверяют ее наличие.
- SOA – используется для указания на новую зону и авторитетность указанной в ней информации.
- SPF – защищает домен от подделки, показывает список доверенных серверов, с которых отправляются электронные письма. Это нужно для того, чтобы предотвратить рассылку спама от вашего доменного имени.
- SRV – хранит данные о местоположении серверов, обеспечивающих работу тех или иных служб.
- TXT – содержит общую вспомогательную информацию о домене, используется для указания SPF-записей, подтверждения прав собственности, обеспечения безопасности электронной почты и так далее.
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей
Подписаться
Интерактивный режим nslookup
Для входа в интерактивный режим достаточно запустить программу без опций:
nslookup
Любо указать дефис. Кроме дефиса также можно указать имя домена или адрес DNS сервера для запросов:
nslookup - 8.8.4.4
В интерактивном режиме для выполнения DNS запроса указывайте по одному доменному имени, для которого вы хотите узнать IP адрес.
В интерактивной сессии командой
server домен_или_IP
можно установить используемый для запросов DNS сервер, например:
server 8.8.4.4
Можно просмотреть текущие значения всех опций командой:
set all
Пример вывода:
Set options: novc nodebug nod2 search recurse timeout = 0 retry = 3 port = 53 ndots = 1 querytype = A class = IN srchlist =
Значения всех показанных опций можно изменить.
С помощью равнозначных команд:
set querytype=ЗАПИСЬ set type=ЗАПИСЬ
Можно изменить тип запрашиваемой DNS записи, например, чтобы установить тип записи на MX:
set type=MX
После этого все запросы будут делаться с учётом установвленных настроек, то есть например будет показываться только указанный тип записи. Кстати, чтобы узнать о всех типах записях и чем они различаются, а также как вообще работает DNS, смотрите статью «Введение в DNS терминологию, компоненты и концепции».
Чтобы выводились сразу все DNS записи установите эту настройку следующим образом:
set type=ANY
Пример вывода информации о сразу всех найденных DNS записях домена suip.biz:
> suip.biz Server: 8.8.4.4 Address: 8.8.4.4#53 Non-authoritative answer: Name: suip.biz Address: 185.117.153.79 suip.biz nameserver = ns1.marosnet.ru. suip.biz nameserver = ns2.marosnet.ru. suip.biz origin = dns-manager_marosnet_net mail addr = proghoster.gmail.com serial = 2016040402 refresh = 3600 retry = 3600 expire = 604800 minimum = 86400 suip.biz mail exchanger = 10 mail.suip.biz. suip.biz mail exchanger = 20 mail.suip.biz. Name: suip.biz Address: 2a02:f680:1:1100::3d5f Authoritative answers can be found from:
Рекурсивные запросы можно включить или отключить командами:
set recurse set norecurse
По умолчанию рекурсивные запросы включены.
Поменять порт по умолчанию для TCP/UDP соединений при запросах к DNS серверу можно командой вида:
set port=ПОРТ
Портом по умолчанию является 53.
Кроме рассмотренных, имеются и некоторые другие настройки, которые используются реже — время тайм-аута, количество попыток запросов и другие.
Интерактивный nslookup может оказаться полезным если вы хотите сделать ряд поисков по DNS записям и хотите, чтобы они были сделаны с определёнными настройками, которые вы устанавливаете на данную сессию.