Рейтинг:2

Прерывистый SERVFAIL из разных мест — как диагностировать и исправить?

флаг jp

Я запускаю службу в https://asti.ga .

Время от времени я получаю сообщения о том, что люди не могут найти доменное имя (либо NXDOMAIN в браузере, либо SERVFAIL, если копать землюимя через корневой DNS-сервер). Эти сообщения, похоже, исходят из определенных частей мира, особенно из Юго-Восточной Азии.

Я сам редко вижу эти проблемы. Однако я настроил проверку работоспособности Route53 и действительно вижу эти проблемы в определенных местах:

введите описание изображения здесь

Кроме того, я замечаю, что результат не соответствует. Иногда это не удается в месте, иногда это работает. Он может переключаться между SERVFAIL и успешным поиском каждую минуту.

Как понять, что происходит в этих местах?

флаг cn
Кто размещает ваш DNS? Это АВС? На страницах AWS есть дополнительная информация, если это они: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/troubleshooting-domain-unavailable.html.
флаг cn
Выполнение `dig @8.8.8.8 +short NS asti.ga` возвращает что-то похожее на немецкие серверы имен. Это вполне может быть проблемой загрузки/задержки у провайдера. Если вы используете AWS, рассматривали ли вы возможность переноса зоны на Route53?
флаг cn
Bob
Если у вас нет веских причин для того, чтобы значение TTL составляло 300 секунд, исследования показывают, что увеличение значений TTL обычно снижает задержку и делает вашу DNS более надежной. См. https://www.sidnlabs.nl/en/news-and-blogs/how-to-choose-dns-ttl-values.
флаг jp
DNS размещается у Hetzner. Я не использую AWS для этой службы, кроме Route53 для проверки работоспособности.
флаг jp
Спасибо за эту ссылку @Bob. Возможно, серверы Hetzner отказываются отвечать, потому что получают слишком много запросов, так как значение TTL слишком низкое? Но почему это повлияет только на определенные места?
djdomi avatar
флаг za
hetzner имеет много ограничений. 300-секундный ttl должен использоваться в основном только тогда, когда вы пытаетесь переместить свой домен на другой сервер имен или IP-адрес, иначе, как уже говорилось, более высокое значение, например 86400, должно быть в порядке.
флаг jp
@djdomi «У hetzner много ограничений» — можете ли вы сказать, какие они? Я не вижу никаких очевидных вещей в их документах. Я попробую с более высоким TTL.
флаг jp
Похоже, дела пошли лучше — все средства проверки Route53 теперь показывают успехи, а еще одно средство проверки страницы состояния теперь записывает время безотказной работы. Хотели бы вы продвигать свой комментарий к ответу @Bob?
djdomi avatar
флаг za
@dangravell Я использовал hetzner для своего бизнеса и ушел через год, поддержка в основном хорошая, но в случае особых обстоятельств они оставляют вас в покое. DNS-серверы ограничивают слишком много запросов и jzst droo их, но я не уверен, что это действительно через 5-10 лет.
Рейтинг:1
флаг cn
Bob

расширенный из моего предыдущего комментария:

Благодарим вас за публикацию вашего действительного домена. Это позволило мне проверить ваши текущие настройки.

Я заметил, что TTL, время жизни вашей записи DNS было установлено значение 300 секунд.

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

Если у вас нет веских причин для того, чтобы значение TTL составляло 300 секунд, исследования показывают, что увеличение значений TTL обычно снижает задержку и делает вашу DNS более надежной. См. например sidnlabs.nl/en/news-and-blogs/how-to-choose-dns-ttl-значения

Владельцам обычных зон мы рекомендуем более длинные значения TTL: не менее одного часа, а в идеале — четыре, восемь или 24 часа.Предполагая, что плановое техническое обслуживание может быть запланировано заранее, большие TTL обходятся недорого.

флаг jp
Спасибо - это, казалось, помогло. На работу ушло около часа, но затем средства проверки работоспособности Route53 начали показывать успешные проверки.

Ответить или комментировать

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