У меня очень старая привычка использовать утилиту host для простых DNS запросов. Появилась она у меня со времени первой настройки почтового сервера на Linux. Я где-то увидел, что с её помощью можно быстро проверить обратную DNS запись (PTR) для IP адреса, которая необходима для корректной работы почтового сервера на внешнем IP адресе.
Посмотрели обратную DNS запись для IP адреса 77.88.8.1. Соответственно, точно так же можно увидеть IP адрес для A записи.
На мой взгляд это самый простой и быстрый способ решить задачу. Я вообще не видел, чтобы кто-то использовал host. Обычно для резолва делают ping. Но он покажет только один IP адрес, а не все сразу. А их может быть много.
А в то же время:
Для более подробных DNS запросов удобно использовать dig, но этой утилиты чаще всего нет в базовых версиях популярных дистрибутивов. Надо отдельно ставить пакет bind-utils:
Про dig я рассказывал в отдельной заметке, поэтому не буду повторяться. В целом, host может полностью заменить dig, если посмотреть его ключи. Он умеет почти всё то же самое, только вывод покороче. Но у меня так сложилось, что простые запросы делаю через host, а если надо более внимательно посмотреть на разные dns записи, в том числе с указанием разных dns серверов, использую dig. Его ключи как-то быстрее запомнились, особенно выбор dns сервера через @:
Посмотрели MX запись для домена ya.ru через DNS сервер 77.88.8.1. Такие проверки постоянно делаю, когда меняю NS сервера у какого-то домена. Особенно, если их там указано несколько и у разных провайдеров. Убеждаюсь, что все корректно сохранили у себя нужную зону.
Раз уж затронул тему проверки DNS записей, поделюсь ссылкой на полезный онлайн сервис для тех же задач: digwebinterface.com. Это прям линуксовый dig со всеми ключами и выводом, только через браузер.
#dns #terminal
# host 77.88.8.11.8.88.77.in-addr.arpa domain name pointer secondary.dns.yandex.ru.Посмотрели обратную DNS запись для IP адреса 77.88.8.1. Соответственно, точно так же можно увидеть IP адрес для A записи.
# host secondary.dns.yandex.rusecondary.dns.yandex.ru has address 77.88.8.1На мой взгляд это самый простой и быстрый способ решить задачу. Я вообще не видел, чтобы кто-то использовал host. Обычно для резолва делают ping. Но он покажет только один IP адрес, а не все сразу. А их может быть много.
# host dns.googledns.google has address 8.8.4.4dns.google has address 8.8.8.8dns.google has IPv6 address 2001:4860:4860::8844dns.google has IPv6 address 2001:4860:4860::8888А в то же время:
# ping dns.googlePING dns.google (8.8.4.4) 56(84) bytes of data.64 bytes from dns.google (8.8.4.4): icmp_seq=1 ttl=59 time=16.4 msДля более подробных DNS запросов удобно использовать dig, но этой утилиты чаще всего нет в базовых версиях популярных дистрибутивов. Надо отдельно ставить пакет bind-utils:
# apt install bind9-utils# dnf install bind-utilsПро dig я рассказывал в отдельной заметке, поэтому не буду повторяться. В целом, host может полностью заменить dig, если посмотреть его ключи. Он умеет почти всё то же самое, только вывод покороче. Но у меня так сложилось, что простые запросы делаю через host, а если надо более внимательно посмотреть на разные dns записи, в том числе с указанием разных dns серверов, использую dig. Его ключи как-то быстрее запомнились, особенно выбор dns сервера через @:
# dig @77.88.8.1 ya.ru MXПосмотрели MX запись для домена ya.ru через DNS сервер 77.88.8.1. Такие проверки постоянно делаю, когда меняю NS сервера у какого-то домена. Особенно, если их там указано несколько и у разных провайдеров. Убеждаюсь, что все корректно сохранили у себя нужную зону.
Раз уж затронул тему проверки DNS записей, поделюсь ссылкой на полезный онлайн сервис для тех же задач: digwebinterface.com. Это прям линуксовый dig со всеми ключами и выводом, только через браузер.
#dns #terminal
В выходные прочитал любопытную статью про новый тип DNS записей - HTTPS и SVCB. Речь о них ведётся давно. Я вроде раньше уже слышал что-то подобное, но не разбирался, как это работает. Каким образом новая DNS запись HTTPS должна улучшить нашу жизнь? Посмотрел подробности. Расскажу вам простыми словами.
Новая DNS запись HTTPS призвана уменьшить такой параметр, как time-to-first-packet. В общем случае он не сильно знаком админам, но лично я его хорошо знаю с точки зрения SEO. Это один из факторов ранжирования у поисковиков. Чем быстрее сервер отвечает клиенту, тем лучше.
Принцип работы этой записи довольно простой. Она содержит в себе следующую информацию:
◽доменное имя;
◽версия HTTP протокола;
◽IP адрес сервера.
Выглядит это примерно так:
Запрос на получение этой DNS записи делает браузер. В итоге он сразу же получает всю нужную информацию, чтобы выполнить подключение к целевому веб серверу и конкретному урлу без необходимости дополнительных согласований.
Если нет этой записи, то браузер действует следующим образом:
1️⃣ Запрашивает А запись, чтобы выполнить преобразование доменного имени в IP.
2️⃣ Обращается к веб серверу по IP, передав в заголовке имя домена. Выполняет привычные TLS согласования, возможно в процессе изменяет версию протокола HTTP.
3️⃣ Если на сервере настроен редирект, то идёт по этому редиректу. В HTTPS записи можно сразу указать нужный url, на которой пойдёт браузер при обращении к конкретному домену.
В статье приведён пример с доменом https.test.netmeister.org и соответствующей HTTPS записью:
Браузер при обращении к урлу https.test.netmeister.org сразу же идёт на сервер 166.84.7.99 по протоколу h2 и просит урл www.netmeister.org, не дожидаясь редиректа веб сервера. При этом A записи нет вообще. При наличии HTTPS записи она становится не нужна. В статье в том числе показан сетевой дамп при выполнении подобного запроса.
В целом, поддержка HTTPS записей уже принята и описана в RFC. Например, утилита
Может кто-то уже использует эти записи и знает хостеров, которые их поддерживают?
#dns
Новая DNS запись HTTPS призвана уменьшить такой параметр, как time-to-first-packet. В общем случае он не сильно знаком админам, но лично я его хорошо знаю с точки зрения SEO. Это один из факторов ранжирования у поисковиков. Чем быстрее сервер отвечает клиенту, тем лучше.
Принцип работы этой записи довольно простой. Она содержит в себе следующую информацию:
◽доменное имя;
◽версия HTTP протокола;
◽IP адрес сервера.
Выглядит это примерно так:
example.com. 1800 IN HTTPS 1 . alpn=h3,h2 ipv4hint=1.2.3.4 ipv6hint=2001:470:30:84:e276:63ff:fe72:3900 Запрос на получение этой DNS записи делает браузер. В итоге он сразу же получает всю нужную информацию, чтобы выполнить подключение к целевому веб серверу и конкретному урлу без необходимости дополнительных согласований.
Если нет этой записи, то браузер действует следующим образом:
1️⃣ Запрашивает А запись, чтобы выполнить преобразование доменного имени в IP.
2️⃣ Обращается к веб серверу по IP, передав в заголовке имя домена. Выполняет привычные TLS согласования, возможно в процессе изменяет версию протокола HTTP.
3️⃣ Если на сервере настроен редирект, то идёт по этому редиректу. В HTTPS записи можно сразу указать нужный url, на которой пойдёт браузер при обращении к конкретному домену.
В статье приведён пример с доменом https.test.netmeister.org и соответствующей HTTPS записью:
www.netmeister.org. alpn="h2,http/1.1" ipv4hint=166.84.7.99Браузер при обращении к урлу https.test.netmeister.org сразу же идёт на сервер 166.84.7.99 по протоколу h2 и просит урл www.netmeister.org, не дожидаясь редиректа веб сервера. При этом A записи нет вообще. При наличии HTTPS записи она становится не нужна. В статье в том числе показан сетевой дамп при выполнении подобного запроса.
В целом, поддержка HTTPS записей уже принята и описана в RFC. Например, утилита
dig их поддерживает. Я проверил. Современные браузеры тоже поддерживают. Зашёл к DNS хостингам, которыми пользуюсь. Там возможности добавить HTTPS запись нет. То есть на практике пока не получается ими пользоваться. А так удобно сделано. Как только появится поддержка у хостеров, надо будет настроить.Может кто-то уже использует эти записи и знает хостеров, которые их поддерживают?
#dns
Я делал несколько заметок на тему systemd, где встроенные возможности этой системы управления службами заменяют функциональность других линуксовых программ и утилит:
◽Systemd timers как замена Cron
◽Journald как замена Syslog
◽Systemd-journal-remote - централизованное хранение логов
◽Systemd-journal-gatewayd - просмотр логов через браузер
◽Systemd-mount для монтирования дисков
◽Есть ещё timesyncd как замена ntp или chrony.
Сегодня расскажу про ещё одну такую службу, которая заменяет локальный кэширующий DNS сервер - systemd-resolved. Изначально я научился настраивать DNS сервер Bind ещё в те времена, когда было привычным делом держать свою зону на своих серверах. Везде использовал его, даже в простых случаях, где нужно простое кэширование без поддержки своих зон. Потом познакомился с Dnsmasq и для обычного кэширования стал использовать его, так как настроить быстрее и проще. На пути к упрощению решил попробовать systemd-resolved. Он выступает в роли локального кэширующего сервера, то есть обрабатывает только запросы сервера, где он установлен, и его приложений.
В каких-то дистрибутивах systemd-resolved может быть в составе systemd. В Debian 12 это не так, поэтому придётся поставить отдельно:
Далее открываем конфиг
Это минимальный набор настроек для локального кэширующего сервера. Сервера из списка FallbackDNS будут использоваться в случае недоступности основного списка.
Перезапускаем службу:
После установки systemd-resolved удаляет
или так:
То есть локальный DNS сервис имеет адрес 127.0.0.54. Он же и указан в виде
Посмотреть статус службы можно так:
Если захотите посмотреть подробности работы службы, например, увидеть сами запросы и узнать сервера, к которым они были переадресованы, то можно включить режим отладки.
Добавляем параметр:
Перезапускаем службу и смотрим логи:
Если ответа нет в кэше, то вы увидите информацию о том, что был запрос к публичному DNS серверу. Если в кэше есть запись об этом домене, то увидите строку:
Посмотреть статистику по запросам:
Очистить локальный кэш:
В принципе, простой и эффективный инструмент. Можно пользоваться, особенно если он идёт в комплекте с systemd. Было бы интересно его приспособить и для удалённых запросов. Например, поставить на гипервизор и обслуживать запросы виртуальных машин. Но как я понял, он так не умеет и не предназначен для этого.
#systemd #dns
◽Systemd timers как замена Cron
◽Journald как замена Syslog
◽Systemd-journal-remote - централизованное хранение логов
◽Systemd-journal-gatewayd - просмотр логов через браузер
◽Systemd-mount для монтирования дисков
◽Есть ещё timesyncd как замена ntp или chrony.
Сегодня расскажу про ещё одну такую службу, которая заменяет локальный кэширующий DNS сервер - systemd-resolved. Изначально я научился настраивать DNS сервер Bind ещё в те времена, когда было привычным делом держать свою зону на своих серверах. Везде использовал его, даже в простых случаях, где нужно простое кэширование без поддержки своих зон. Потом познакомился с Dnsmasq и для обычного кэширования стал использовать его, так как настроить быстрее и проще. На пути к упрощению решил попробовать systemd-resolved. Он выступает в роли локального кэширующего сервера, то есть обрабатывает только запросы сервера, где он установлен, и его приложений.
В каких-то дистрибутивах systemd-resolved может быть в составе systemd. В Debian 12 это не так, поэтому придётся поставить отдельно:
# apt install systemd-resolvedДалее открываем конфиг
/etc/systemd/resolved.conf и приводим его примерно к такому виду:[Resolve]DNS=77.88.8.1 1.1.1.1 8.8.8.8FallbackDNS=77.88.8.8 8.8.4.4Cache=yesЭто минимальный набор настроек для локального кэширующего сервера. Сервера из списка FallbackDNS будут использоваться в случае недоступности основного списка.
Перезапускаем службу:
# systemctl restart systemd-resolvedПосле установки systemd-resolved удаляет
/etc/resolv.conf и заменяет ссылкой на /run/systemd/resolve/stub-resolv.conf. Проверить работу службы можно разными способами. Например так:# resolvectl query ya.ruили так:
# dig @127.0.0.54 ya.ruТо есть локальный DNS сервис имеет адрес 127.0.0.54. Он же и указан в виде
nameserver 127.0.0.53 в resolv.conf. Посмотреть статус службы можно так:
# resolvectl statusЕсли захотите посмотреть подробности работы службы, например, увидеть сами запросы и узнать сервера, к которым они были переадресованы, то можно включить режим отладки.
# systemctl edit systemd-resolvedДобавляем параметр:
[Service]Environment=SYSTEMD_LOG_LEVEL=debugПерезапускаем службу и смотрим логи:
# systemctl restart systemd-resolved# journalctl -f -u systemd-resolvedЕсли ответа нет в кэше, то вы увидите информацию о том, что был запрос к публичному DNS серверу. Если в кэше есть запись об этом домене, то увидите строку:
Positive cache hit for example.com IN AПосмотреть статистику по запросам:
# resolvectl statisticsОчистить локальный кэш:
# resolvectl flush-cachesВ принципе, простой и эффективный инструмент. Можно пользоваться, особенно если он идёт в комплекте с systemd. Было бы интересно его приспособить и для удалённых запросов. Например, поставить на гипервизор и обслуживать запросы виртуальных машин. Но как я понял, он так не умеет и не предназначен для этого.
#systemd #dns
Каких только top-ов в Linux нет. Встречайте ещё один, про который большинство скорее всего не слышали - dnstop. Живёт в базовых репах:
Пригодится в основном на локальном dns сервере, но не обязательно только там. С помощью dnstop можно в режиме реального времени смотреть статистику dns запросов, как приходящих на сервер, так и исходящих от него самого.
Для запуска надо указать сетевой интерфейс, который будем слушать:
Если хотите сразу исключить локальные запросы сервера, то исключите его IP адрес с помощью ключа -i:
После запуска вы увидите основной экран с IP адресами источников запросов и количеством запросов. С помощью клавиш вы можете выбрать различные режимы отображения информации:
◽ s - таблица source address, экран по умолчанию после запуска
◽ d - таблица destination address
◽ t - статистика по типам запросов
◽ r - таблица кодов ответов
◽ @ - таблица source + адреса доменов 2-го уровня в запросе
Это не все горячие клавиши. Я перечислил только те, что показались полезными. Остальные возможности можно посмотреть в man.
По своей сути dnstop похож на tcpdump, потому что использует библиотеку libpcap, только она анализирует исключительно dns запросы. Результат работы можно сохранить в pcap файл с помощью ключа
#dns #perfomance
# apt install dnstopПригодится в основном на локальном dns сервере, но не обязательно только там. С помощью dnstop можно в режиме реального времени смотреть статистику dns запросов, как приходящих на сервер, так и исходящих от него самого.
Для запуска надо указать сетевой интерфейс, который будем слушать:
# dnstop eth0Если хотите сразу исключить локальные запросы сервера, то исключите его IP адрес с помощью ключа -i:
# dnstop eth0 -i 10.20.1.2После запуска вы увидите основной экран с IP адресами источников запросов и количеством запросов. С помощью клавиш вы можете выбрать различные режимы отображения информации:
◽ s - таблица source address, экран по умолчанию после запуска
◽ d - таблица destination address
◽ t - статистика по типам запросов
◽ r - таблица кодов ответов
◽ @ - таблица source + адреса доменов 2-го уровня в запросе
Это не все горячие клавиши. Я перечислил только те, что показались полезными. Остальные возможности можно посмотреть в man.
По своей сути dnstop похож на tcpdump, потому что использует библиотеку libpcap, только она анализирует исключительно dns запросы. Результат работы можно сохранить в pcap файл с помощью ключа
savefile.#dns #perfomance
Один подписчик поделился со мной информацией о необычном и полезном программном продукте. Изначально он обратился ко мне с просьбой подсказать, какой веб сервер под Windows можно использовать для быстрого запуска локально с флешки размещённого там небольшого проекта. Первое, что мне пришло в голову - Caddy. Это максимально простой веб сервер, состоящий из одного бинарника на Go, который всю конфигурацию хранит в едином конфиге. Версия под Windows тоже есть.
Он в итоге нашёл для себя вариант ещё проще и лучше - Small HTTP server. Пошёл, посмотрел, что это такое. Очень заинтересовала программа. Раньше про неё не слышал. Она из далёкого прошлого. Написана изначально была под Windows 95 и NT, но развивается до сих пор. Свежий релиз от 24.03.24. Код, как я понял, написан на С++ и очень хорошо оптимизирован. Установщик занимает примерно 1 мегабайт (❗️). При этом программа имеет следующие возможности:
◽HTTP сервер. Поддерживает CGI и FastCGI интерфейсы для скриптов (запуск исполняемых файлов; Perl, PHP, и других внешних интерпретаторов), ISAPI (Internet Server API — API для веб-сервера IIS) интерфейс, виртуальные хосты и каталоги.
◽Почтовый сервер POP3 и SMTP. Анти-спам фильтры. Белый, чёрный, и серый списки общие для всех и персональные для каждого пользователя. Переотправка и возможности запускать скрипты для входящих сообщений. Запуск внешнего антивируса.
◽FTP сервер с виртуальными каталогами.
◽HTTP proxy сервер. Поддерживаются HTTP, FTP, HTTPS запросы
Сохранение большого объема трафика, быстрый доступ. Внутренняя докачка при разрывах соединения. Сервер может запрашивать сжатый контент и распаковывать ответ на лету (с использованием внешней Zlib библиотеке).
◽DNS сервер. 🔥Опция динамической проверки сервиса на удаленном хосту и если сервис не работает, автоматическая замена одного IP адреса на другой во всех запросах. Рекурсивный поиск имен от корневых DNS серверов или от DNS серверов провайдера. Кеширование. Опция автоматического ответа на запросы IPv6 адреса. (для сетей, не использующих Internet по IPv6). DNSBL сервер (работает совместно с SMTP). DNS через HTTP(S) известный как DoH (RFC8484).
◽DHCP сервер.
◽HTTP TLS VPN сервер и клиент! Используется OpenVPN Windows TAP драйвер. Описание, как это работает и для чего.
Всё это собрано под Windows и Linux, в том числе ARM. Для Debian есть готовый пакет. Хорошее решение для маломощных одноплатников.
По работе всех служб есть статистика в веб интерфейсе. Я попробовал работу на Windows. Всё работает чётко, запустил без каких-либо проблем. Конфигурация хранится в текстовом файле. Управлять можно как в нём, так и через интерфейс программы. Для запуска достаточно запустить экзешник. По умолчанию веб сервер работает в режиме листинга файлов директории, которая указана, как корень веб сервера. Можно настроить работу как служба.
У программы, несмотря на видимую простоту, очень много настроек и возможностей. Они все перечислены в виде параметров в интерфейсе программы, так что можно быстро их оценить.
Предлагаю автору накидать звёздочек в github и подписаться на Telegram канал. Думаю, ему будет приятно. Программа реально интересная и необычная. Не знаю, что за мотивация у человека столько лет её развивать и поддерживать.
Мне кажется, сейчас программистов С++ уже можно по профильным школам и вузам водить, как ветеранов, и рассказывать от их лица, что программы могут быть маленькими, оптимизированными и работать быстро. А то скоро все вообще забудут, что такое в принципе может быть.
⇨ Сайт / Исходники / TG канал
#webserver #dns #dhcp #ftp
Он в итоге нашёл для себя вариант ещё проще и лучше - Small HTTP server. Пошёл, посмотрел, что это такое. Очень заинтересовала программа. Раньше про неё не слышал. Она из далёкого прошлого. Написана изначально была под Windows 95 и NT, но развивается до сих пор. Свежий релиз от 24.03.24. Код, как я понял, написан на С++ и очень хорошо оптимизирован. Установщик занимает примерно 1 мегабайт (❗️). При этом программа имеет следующие возможности:
◽HTTP сервер. Поддерживает CGI и FastCGI интерфейсы для скриптов (запуск исполняемых файлов; Perl, PHP, и других внешних интерпретаторов), ISAPI (Internet Server API — API для веб-сервера IIS) интерфейс, виртуальные хосты и каталоги.
◽Почтовый сервер POP3 и SMTP. Анти-спам фильтры. Белый, чёрный, и серый списки общие для всех и персональные для каждого пользователя. Переотправка и возможности запускать скрипты для входящих сообщений. Запуск внешнего антивируса.
◽FTP сервер с виртуальными каталогами.
◽HTTP proxy сервер. Поддерживаются HTTP, FTP, HTTPS запросы
Сохранение большого объема трафика, быстрый доступ. Внутренняя докачка при разрывах соединения. Сервер может запрашивать сжатый контент и распаковывать ответ на лету (с использованием внешней Zlib библиотеке).
◽DNS сервер. 🔥Опция динамической проверки сервиса на удаленном хосту и если сервис не работает, автоматическая замена одного IP адреса на другой во всех запросах. Рекурсивный поиск имен от корневых DNS серверов или от DNS серверов провайдера. Кеширование. Опция автоматического ответа на запросы IPv6 адреса. (для сетей, не использующих Internet по IPv6). DNSBL сервер (работает совместно с SMTP). DNS через HTTP(S) известный как DoH (RFC8484).
◽DHCP сервер.
◽HTTP TLS VPN сервер и клиент! Используется OpenVPN Windows TAP драйвер. Описание, как это работает и для чего.
Всё это собрано под Windows и Linux, в том числе ARM. Для Debian есть готовый пакет. Хорошее решение для маломощных одноплатников.
По работе всех служб есть статистика в веб интерфейсе. Я попробовал работу на Windows. Всё работает чётко, запустил без каких-либо проблем. Конфигурация хранится в текстовом файле. Управлять можно как в нём, так и через интерфейс программы. Для запуска достаточно запустить экзешник. По умолчанию веб сервер работает в режиме листинга файлов директории, которая указана, как корень веб сервера. Можно настроить работу как служба.
У программы, несмотря на видимую простоту, очень много настроек и возможностей. Они все перечислены в виде параметров в интерфейсе программы, так что можно быстро их оценить.
Предлагаю автору накидать звёздочек в github и подписаться на Telegram канал. Думаю, ему будет приятно. Программа реально интересная и необычная. Не знаю, что за мотивация у человека столько лет её развивать и поддерживать.
Мне кажется, сейчас программистов С++ уже можно по профильным школам и вузам водить, как ветеранов, и рассказывать от их лица, что программы могут быть маленькими, оптимизированными и работать быстро. А то скоро все вообще забудут, что такое в принципе может быть.
⇨ Сайт / Исходники / TG канал
#webserver #dns #dhcp #ftp
Предлагаю попробовать и забрать в закладки сервис по проверке DNS записей:
⇨ https://zonemaster.net
Я даже и не знал, что существует столько параметров, по которым можно проверить домен. Сервис полностью бесплатен, исходный код открыт. Можно развернуть у себя и делать проверки через JSON-RPC API.
Для полноценной работы нужно будет поднять Zonemaster-CLI (есть собранный Docker контейнер), Zonemaster-Backend (отвечает за API), Zonemaster-GUI (веб интерфейс). Инструкции все здесь.
Домен проверяется по 50-ти проверкам. Для теста прогнал свой домен serveradmin.ru. Набралось приличное количество ошибок и замечаний. Все они прокомментированы, так что в целом понятно, о чём там речь. Особо критичного ничего нет, а некоторые замечания относятся к DNS хостингу, на который я повлиять не могу. В качестве DNS серверов для домена у меня указаны сервера Selectel и Yandex.
Пример замечаний:
◽NS сервера Selectel не имеют PTR записей. Дублирующие их сервера Яндекса имеют. Странно, что в Selectel на это забили.
◽Разные номера SOA записей у DNS серверов. Так как я использую двух разных провайдеров, это нормально. Они должны совпадать в рамках одного провайдера.
🔥Здесь реальная ошибка нашлась. В какой-то момент NS сервера Selectel изменили свои доменные имена. И я забыл их обновить в записях Yandex. В итоге зона в Yandex имела NS сервера ns1.selectel.org и ns2.selectel.org вместо актуальных ns1.selectel.ru и ns2.selectel.ru.
◽Ещё одна небольшая ошибка была. Различались TTL у MX записей у разных провайдеров. Поправил. Параметры должны везде быть идентичными для одних и тех же записей.
В общем, сервис полезный. Рекомендую взять на вооружение и проверять свои домены. Особенно если зоны держат разные серверы и провайдеры, а записей много.
⇨ Сайт / Исходники
#dns #сервис
⇨ https://zonemaster.net
Я даже и не знал, что существует столько параметров, по которым можно проверить домен. Сервис полностью бесплатен, исходный код открыт. Можно развернуть у себя и делать проверки через JSON-RPC API.
Для полноценной работы нужно будет поднять Zonemaster-CLI (есть собранный Docker контейнер), Zonemaster-Backend (отвечает за API), Zonemaster-GUI (веб интерфейс). Инструкции все здесь.
Домен проверяется по 50-ти проверкам. Для теста прогнал свой домен serveradmin.ru. Набралось приличное количество ошибок и замечаний. Все они прокомментированы, так что в целом понятно, о чём там речь. Особо критичного ничего нет, а некоторые замечания относятся к DNS хостингу, на который я повлиять не могу. В качестве DNS серверов для домена у меня указаны сервера Selectel и Yandex.
Пример замечаний:
◽NS сервера Selectel не имеют PTR записей. Дублирующие их сервера Яндекса имеют. Странно, что в Selectel на это забили.
◽Разные номера SOA записей у DNS серверов. Так как я использую двух разных провайдеров, это нормально. Они должны совпадать в рамках одного провайдера.
🔥Здесь реальная ошибка нашлась. В какой-то момент NS сервера Selectel изменили свои доменные имена. И я забыл их обновить в записях Yandex. В итоге зона в Yandex имела NS сервера ns1.selectel.org и ns2.selectel.org вместо актуальных ns1.selectel.ru и ns2.selectel.ru.
◽Ещё одна небольшая ошибка была. Различались TTL у MX записей у разных провайдеров. Поправил. Параметры должны везде быть идентичными для одних и тех же записей.
В общем, сервис полезный. Рекомендую взять на вооружение и проверять свои домены. Особенно если зоны держат разные серверы и провайдеры, а записей много.
⇨ Сайт / Исходники
#dns #сервис