Назад | Перейти на главную страницу

Распространение DNS частично выполнено

Несколько недель назад я запустил авторитетный сервер 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).