Google Cloud DNS изменяет время обновления ресурса записи

Question

В настоящее время я пытаюсь сопоставить виртуальную машину Compute Engine с эфемерным IP-адресом с именем хоста с помощью Google Cloud DNS, эта операция выполняется во время запуска виртуальной машины.Я делаю это с помощью сценария оболочки следующим образом:

gcloud dns record-sets transaction start -z=MY_ZONE
gcloud dns record-sets transaction remove --zone MY_ZONE \
    --name subd.domain.com \
    --type A "1.2.3.4" \ #the old external ip for the VM
    --ttl 300
gcloud dns record-sets transaction add --zone MY_ZONE \
    --name subd.domain.com \
    --type A "5.6.7.8" \ #the new external ip for the VM
    --ttl 300
gcloud dns record-sets transaction execute -z=MY_ZONE

После запуска сценария я вижу записи, успешно измененные в облачном пользовательском интерфейсе DNS, с RR «A», имеющим новый внешний IP.

Что происходит сейчас, так это то, что эти изменения действительно очень долго вступают в силу.Доступ к имени хоста «subd.domain.com» после изменения возвращает статус «NXDOMAIN», длящийся в течение длительного периода времени и только после этого он, наконец, сопоставляет домен с новым IP.

В этой ситуации возникли два вопросадля меня:

# 1 Почему DNS проходит фазу NXDOMAIN?Если эти изменения не действуют как Update (из-за выполнения этого в транзакции), а не как Remove, тогда Create.

# 2 Что определяет время дляэто обновление записи, чтобы начать жить?

Answer 1

Изменения DNS распространяются (распространяются) несколькими различными способами. Эти различные способы развивались по мере развития DNS и могут быть найдены в различных RFC (https://www.isc.org/community/rfcs/dns/).

В вашем примере вы пытаетесь изменить запись A (сопоставление IP-адреса с именем) для ресурса в DNS-зоне "domain.com". Метод, который вы показываете, сначала удаляет старую запись, а затем добавляет новую, используя «транзакцию». Стиль использования «транзакции» является уникальным для предложения Google Cloud DNS, не является частью задокументированного RFC и может (или не может) влиять на скорость, с которой завершается успешное разрешение. (Примечание: транзакция, даже если она включает в себя несколько изменений DNS, в моем тестировании только увеличивает последовательность SOA на 1)

Во-первых, я хочу рассказать немного о технике.

Есть несколько серверов, которые функционируют как «авторитетный» источник для записей для этой зоны (domain.com). Те серверы, которые являются авторитетными, перечислены в записи NS для зоны. Это серверы, которые будут отвечать на запросы, когда кто-то в браузере пытается найти это имя или кто-то пытается пропинговать его, и т. Д. Способ доступа к этим серверам, когда кто-то пингует или кто-то пытается получить к нему доступ в браузере, сильно варьируется. и за его пределами (в Google "разрешение DNS клиента")

Как правило, Google Cloud DNS предоставляет вам четыре авторитетных сервера с именами, такими как для любой вновь созданной зоны:

• ns-cloud-a1.googledomains.com
• ns-cloud-a2.googledomains.com
• ns-cloud-a3.googledomains.com
• ns-cloud-a4.googledomains.com

Утилиты запроса DNS-имен, такие как "dig" или "nslookup", могут использоваться для запроса статуса каждого из этих авторитетных серверов в отдельности.

Теперь, когда вы запускаете команду "gcloud dns ..." для удаления и / или добавления записи, она не использует документированные методы DNS для облегчения передачи записей на все авторитетные серверы. Лучшее, что я могу сказать из своего тестирования, это то, что оно сначала обновляет некоторую центральную базу данных с вашими изменениями, а затем запускает процесс обновления (возможно, с помощью уведомлений в стиле DNS?) Самих серверов. Это видно по тому факту, что пользовательский интерфейс Google Cloud DNS может иногда показывать ваше обновление до того, как какой-либо из авторитетных серверов фактически зарегистрирует изменение вашей транзакции.

Далее, поскольку изменение отправляется и / или обрабатывается набором авторитетных серверов, кажется, что требуется некоторое время, чтобы полностью согласоваться на каждом сервере. (Зак Бьорнсон опубликовал этот анализ времени для добавления записей DNS с использованием GCP и AWS для конвергенции вместе с кодом для самостоятельного анализа в http://blog.zachbjornson.com/2018/08/14/dns-propagation.html.)

Одна из его диаграмм показывает время достижения согласованности: Время обновления DNS-серверов GCP

Хотя каждый из четырех серверов, перечисленных выше (ns-cloud-xxx ...), имеет только один IP-адрес, они являются произвольными IP-адресами, что означает, что они могут находиться в нескольких сетях в нескольких центрах обработки данных. Таким образом, хотя ns-cloud-a1.googledomains.com разрешает 216.239.32.106, этот IP может существовать на серверах в Майами, Тампа, Орландо, Атланте и некоторых других местах. Когда вы пытаетесь связаться с ним, сети, через которые проходит ваш поток, приведут вас к ближайшей (спасибо @BGP!). В моем тестировании (выполнение dig 20 раз в секунду для каждого из опубликованных серверов имен googledomains.com для домена, в котором выполняется транзакция, аналогичная той, которую вы опубликовали), выясняется, что изменение медленно сходится, что означает, что для первые несколько секунд это старый IP (тот, который удаляется), а затем запросы на копирование начинают показывать, что он меняется, но это может быть только один запрос из каждых 40 или 50, которые показывают новый IP. В течение следующей минуты или около того новый IP возвращается все чаще и чаще, пока 100% запросов не покажут новый IP.

В моем ограниченном тестировании я никогда не получал NXDOMAIN для протестированных записей, все (несколько тысяч) запросов либо возвращали старый или новый IP для перезаписанной записи.

Теперь, на этом этапе, все авторитетные серверы сошлись к новому IP-адресу для записи A "subd.domain.com". DNS-распознаватели или клиенты, вероятно, имеют своего рода локальный кэш, который они используют для минимизации сетевых запросов на часто запрашиваемые записи. Некоторые из этих клиентов будут уважать TTL (время жизни) запрошенной записи, но некоторые могут этого не делать (я не видел много соответствия с реализациями IMHO). TTL - это «предложение», которому могут следовать те, кто запрашивает запись, чтобы обеспечить хороший баланс между минимизацией сетевого трафика и обеспечением точности значения записи. Итак, теперь клиент может иметь старую запись, кэшированную для TTL, поэтому ему может потребоваться истечь, прежде чем он попытается запросить запись снова. В вашем примере TTL 300 равен 300 секундам, то есть 5 минутам, так что вы можете ждать до 5 минут.

Answer 2

Я предложу это предложение, основываясь на многолетнем опыте DNS.Не рассматривайте DNS как базу данных по требованию.Экосистема DNS не предназначена для поддержки того, что вы пытаетесь сделать.Каждая ссылка в цепочке кэширует записи DNS.Вы не можете контролировать этот процесс.В вашем примере ваш TTL составляет 300 секунд.Пройдет как минимум 5 минут до истечения срока действия вашего следующего сервера выше вашего.Многие кэши игнорируют ваш TTL и устанавливают его на часы, а иногда даже дни.Вы должны сделать так, чтобы настройки DNS были «согласованными», а не «мгновенно согласованными».В конечном итоге означает часы или дни.

При планировании изменений DNS я планирую минимум 48 часов, чтобы изменения вступили в силу.Это означает, что мы поддерживаем службы для старой записи DNS, пока новая запись DNS вступает в силу.