Я думаю, что вы смешиваете две вещи: задержку между вашими обновлениями в веб-интерфейсе вашего провайдера и изменениями на всех авторитетных серверах имен Route53 с одной стороны, а с другой стороны после смены авторитетных серверов имен задержка для всех рекурсивных имена серверов в мире, чтобы быть в курсе. Первый случай зависит только от инфраструктуры Amazon. Но вы можете запросить у его авторитетных серверов имен и посмотреть, опубликован ли ресурс. Второй случай на самом деле не является распространением и зависит от TTL и отрицательных TTL.
Итак, я остановлюсь больше на втором случае.
Методология проста:
- начните с запроса к авторитетным серверам имен для вашего ресурса, дважды проверьте правильность ответа. Для этого вы даже можете использовать онлайн-инструменты для устранения неполадок: https://zonemaster.net/ и https://graphviz.net/
- После этого настало время проверить рекурсивные серверы имен по всему миру.
Сначала немного терминологии. Каждый использует этот термин, но «распространение» неправильно в контексте DNS. Потому что когда вы изменяете что-то на авторитетных серверах имен, они не передают свои изменения сверху вниз всем остальным рекурсивным серверам имен в мире, как это было бы просто невозможно.
Напротив, рекурсивные серверы имен будут «в какой-то момент» (это зависит как от содержимого зоны, состояния их кэша, так и от локальных политик) после того, как запрос, перенаправленный на них (кроме редких случаев автоматического обновления кэша), снова свяжется с одним авторитетного сервера имен и вытащить новейшие данные.
Итак, вы можете начать опрашивать некоторые «известные» открытые рекурсивные серверы имен, чтобы узнать, чему они научились для вашего ресурса: 1.1.1.1, 8.8.8.8 или 9.9.9.9, помимо ваших локальных (работающих на ваших собственных серверах). или с использованием вашего провайдера), и может быть полезно использовать более одного, поскольку их кэши будут находиться в разных состояниях, что повлияет на результаты, как описано выше.
Вот некоторые подробности о том, что именно происходит, когда вы запрашиваете конкретный рекурсивный сервер имен для вашего ресурса:
- если его кэш-память полностью пуста для вашего домена / ресурса (например, он только что был перезагружен), он немедленно запросит информацию у полномочного сервера имен, следовательно, ваше изменение будет сразу же видно ему и всем его клиентам
- этот ресурс будет кэшироваться сервером имен на основе TTL, предоставленного официальным. «Обычно» - это максимальное количество времени, в течение которого запись будет оставаться в рекурсивном кэше, в течение которого она не будет запрашивать вновь у полномочных серверов имен, чтобы проверить, изменилось ли что-то. Два важных момента: во-первых, консенсус заключается в том, что стандарты предписывают, чтобы оно было максимальным значением, поэтому кэши могут быть очищены до него (например, кэши с ограниченным пространством могут захотеть удалить старые записи, чтобы освободить место); во-вторых, известно, что некоторые развертывания серверов имен и / или серверов имен будут изменять значение TTL для любой локальной политики, поэтому они могут расширять его, например, если они считают его слишком низким (это рассматривается как способ противодействия стандарт, но такой случай существует, а люди ставят TTL всего на 1 или 5 секунд, что так же глупо)
- Теперь еще один важный случай, который часто ставит в тупик людей, особенно тех, кто проводит тестирование. Если вы добавляете новый ресурс в свой файл зоны, но запрашиваете его существование непосредственно перед изменением, полномочные серверы имен ответят с помощью NXDOMAIN («этот ресурс не существует»), и эта информация также будет кэшироваться рекурсивными серверами имен на некоторое количество время называется «отрицательный TTL» (это все еще положительное число, действующее как задержка, но называется отрицательным, потому что оно относится к отрицательным ответам, таким как «этот ресурс не существует). Таким образом, вы« загрязняете »кэш, потому что если вы внесите изменения в свои авторитетные серверы имен, и сразу после повторного запроса к вашему рекурсивному серверу он все равно ответит «нет такого ресурса», поскольку у него есть эта информация в кеше.
Таким образом, ключевой момент всегда состоит в том, чтобы четко разделять тесты на авторитетных и рекурсивных серверах имен и полностью знать о свойствах, прикрепленных к рекурсивному кешу.