Несколько недель назад я запустил авторитетный сервер powerdns для домена третьего уровня. Через 2 недели у меня все еще есть некоторые общедоступные DNS, которые не разрешают мои записи, например, Google (8.8.8.8) разрешается, но opendns (208.67.222.220) не разрешается. Я попробовал какой-нибудь инструмент проверки DNS в Интернете и могу сказать, что только 50% общедоступных DNS работают с моей записью.
Как понять почему? Можно ли его подключить к DNSSEC (я не включал)?
Итак, похоже, вы делегировали управление ep.cinebot.it.
на другой сервер имен:
;; AUTHORITY SECTION:
ep.cinebot.it. 3600 IN NS mbox.cinebot.it.
ep.cinebot.it. 3600 IN NS srv1.cinebot.it.
;; ADDITIONAL SECTION:
mbox.cinebot.it. 3600 IN A 51.255.48.120
srv1.cinebot.it. 3600 IN A 51.255.48.120
;; SERVER: 213.251.128.129#53(213.251.128.129) ### ns10.ovh.net
Теперь есть некоторые проблемы:
У вас только один сервер имен; конфигурация, подверженная ошибкам. Вам необходимо иметь как минимум два сервера имен в разных сетях (IANA Технические требования к авторитетным серверам имен).
В 51.255.48.120
не отвечает всем. Это status: SERVFAIL
вместо того NXDOMAIN
. Брандмауэр какой-то есть? А может Fail2Ban со слишком строгой настройкой?
Например. пока DNSViz для test.ep.cinebot.it
в основном показывает, что нет DNSSEC для cinebot.it
(доказывая, что с DNSSEC проблем нет), он также дает явную ошибку, предполагающую проблемы со связью:
Зона ep.cinebot.it: сервер (ы) не отвечал на запросы по TCP. (51.255.48.120)
С участием +trace
Я получаю стабильные результаты от 1.1.1.1
(Cloudflare) и 208.67.222.220
(OpenDNS), а иногда даже из 8.8.8.8
/ 8.8.4.4
(Google):
$ dig test.ep.cinebot.it +trace +tcp @1.1.1.1
;; communications error to 51.255.48.120#53: end of file
;; communications error to 51.255.48.120#53: end of file
Это заставило меня также проверить, связана ли проблема с соединениями UDP или TCP, но похоже, что ваш сервер отвечает одинаково с обоими dig +tcp
и +notcp
:
;; ANSWER SECTION:
test.ep.cinebot.it. 60 IN A 93.42.126.242
;; Query time: 27 msec
;; SERVER: 51.255.48.120#53(51.255.48.120)
Кроме того, у вас очень низкий TTL (60 секунд). Это означает, что рекурсивные серверы имен не будут кэшировать ответы в течение длительного времени, что подчеркивает важность отзывчивых и избыточных серверов имен.
После небольшой отладки, благодаря ответу Esa, проблема была в моем DNS-сервере. Я обнаружил, что «;; ошибка связи с ...» была не проблемой достижимости, а пустым ответом DNS-сервера.
Причиной пустого ответа была ошибка бэкэнда DNS (power-dsn с mysql).