Это может быть конкретный вопрос Windows DNS или общий вопрос передовой практики DNS - я не уверен!
Мы перенесли нашу стороннюю службу DNS с провайдера A на провайдера B.
Я заметил, что на наших внутренних рекурсивных DNS-серверах Windows все еще были кэшированные записи NS для наших доменов, указывающие на серверы провайдера A, хотя я несколько дней назад изменил серверы имен с помощью нашего регистратора, и даже несмотря на то, что выбор свойств кэшированных записей показал TTL 1 день.
По прошествии 24 часов, когда срок действия NS-записей в этом кэше истек, вернется ли DNS-сервер к серверу TLD для обновления полномочий или он предпочтет dns1.providera.com, поскольку это то, что он кэшировал?
В этом случае я решил оставить серверы провайдера А включенными на неделю, чтобы изменения могли распространяться, поэтому dns1.providera.com все еще активен и по-прежнему будет предоставлять записи NS и SOA, в которых указано, что dns1.providera.com. отвечал за этот домен. Учитывая этот факт, сможет ли DNS-сервер Windows когда-либо вернуться к TLD и принять изменения полномочий, или он просто предположит, что все в порядке, и обновит временные метки в своих кэшированных записях NS?
Интересно, как лучше всего обеспечить, чтобы это улавливалось кешами? Нужно ли мне:-
(1) Оставьте серверы провайдера A на месте и активными и подождите, пока кеши наверстают упущенное ... в основном то, что мы делаем сейчас, что, похоже, имеет проблемы - возможно, специально для серверов Windows или, возможно, более широко. (2) Оставьте серверы провайдера A на месте, но измените информацию NS и / или SOA, которую они предоставляют, чтобы сообщить кешам, что за них отвечают новые серверы. (3) Удалите серверы провайдера A после 2 * TTL, чтобы принудительно обновить оставшиеся кеши.
Проблема с (2) заключается в том, что в системе поставщика A я не могу изменить информацию NS или SOA на что-либо, кроме их серверов.
Проблема с (3) заключается в том, что я не уверен, как DNS-сервер будет вести себя в этом случае. Когда он не может достичь кэшированных серверов имен, очистит ли он свой кеш и попытается выполнить полный рекурсивный поиск, или он просто вернет ошибку, заставляя пользователя очистить кеш вручную?
Заранее спасибо!
Общая архитектура / поток этих обновлений:
После того, как вы обновите записи с помощью своего регистратора, он обновит базу данных реестра, которая, в свою очередь, обновит скрытый первичный NS TLD.
Обновления будут поступать от скрытого первичного сервера к вторичным серверам, которые фактически отвечают на запросы. Это происходит во время периода обновления SOA TLD, если только не произойдет сбоев, и в этом случае начнется отсчет времени истечения срока действия SOA TLD.
Если с их стороны все в порядке, эти обновления распространяются при максимальном обновлении SOA TLD, и ваша обновленная запись появляется на общедоступных серверах имен TLD.
Если вы сделали запрос до того, как обновленная запись появилась на общедоступных серверах имен TLD, вам придется подождать, пока истечет TTL записи, прежде чем вы получите обновленную запись.
В заключение:
Если все системы отключены, вам нужно только дождаться максимального времени обновления TLD SOA.
Если вы сделали свой запрос через кеширование / рекурсию слишком рано, вам может потребоваться дождаться обновления TLD SOA + TTL записи
Если произойдет сбой, возможно, придется подождать дольше.
Если системы возвращаются в последний возможный момент после сбоя, вам не нужно ждать дольше, чем срок действия SOA TLD + TTL записи. Это объясняется тем фактом, что вы сделали запрос до того, как обновленные записи были опубликованы на общедоступных серверах имен TLD.
Поскольку большинство кэширующих / рекурсивных серверов также будут кэшировать записи вашей зоны, а ваш (корпоративный?) DNS-провайдер, по всей вероятности, также будет иметь вторичные серверы, вам придется добавить обновление SOA, прежде чем вы начнете видеть изменения в вашем собственная зона проходит через новые серверы. Конечно, как и раньше, вы можете обновить как старые, так и новые серверы для своей зоны.
Что вы могли сделать:
Вы можете использовать такой инструмент, как dig или nslookup, чтобы напрямую запросить общедоступные серверы имен TLD, чтобы узнать, обновились ли ваши записи. Вы также узнаете временные значения SOA вашего TLD.
Вы можете использовать те же инструменты, чтобы запросить вторичные серверы вашего нового поставщика DNS, чтобы узнать, уловили ли они изменение.
Выполните полный рекурсивный запрос через общедоступные серверы имен (они могут игнорировать рекурсивное выполнение, но большинство этого не делают), чтобы проверить, работает ли новая цепочка запросов.
Выполните полный рекурсивный запрос локально со своей клиентской рабочей станции. Dig позволяет вам это сделать и поможет определить, связана ли ваша цепочка разрешений должным образом.
DNS может показаться сложным. Напишите комментарии к моему ответу, чтобы я мог сделать его более понятным. Я посмотрю на него позже днем, чтобы увидеть, смогу ли я улучшить то, что я написал.
Не совсем ответ, всего несколько мыслей.
Проблема с (3) заключается в том, что я не уверен, как DNS-сервер будет вести себя в этом случае. Когда он не может связаться с кэшированными серверами имен, очистит ли он свой кеш и попытается выполнить полный рекурсивный поиск, или он просто вернет ошибку, вынуждая пользователя очистить кеш вручную?
BCP 123в разделе 2.1.1 рекомендуется, чтобы в этом случае кэширующий DNS-сервер просто возвращал ошибку. (Кстати, что вы имеете в виду под "пользователем, очищающим кеш вручную"? Пользователь ничего не могу сделать. Оператор DNS-сервера может, и, конечно, администраторам будет все равно, и они даже не узнают о недоступности вашего сервера (если только он не является официальным для google.com). Таким образом, (3) - не очень хороший вариант.
Что касается
Через 24 часа после истечения срока действия NS-записей в этом кэше DNS-сервер вернется к серверу TLD для обновления полномочий.
Я собирался подскочить и сказать: «Конечно, он запросит TLD» просто потому, что в противном случае никто никогда не сможет изменить свой DNS-хостинг. Хотя, если подумать, есть несколько возможностей:
Если какой-то кэширующий DNS-сервер не получил запросов для вашего домена до истечения срока действия NS TTL, а затем после Срок действия NS истек, он получает запрос, кеширует сервер не должен использовать эти NS с истекшим сроком действия и не иметь другого выбора, кроме запроса TLD. Тем не мение, если какой-то кэширующий DNS-сервер постоянно запрашивает ваш домен, ваш старый сервер с каждым запросом может отправлять копию NS-записей (в разделе полномочий), кэширующие серверы вполне могут хранить записи для своего нового TTL, и, таким образом, TTL технически может никогда не истечь ( ?!)
Я полагаю, что TLD будут опрошены просто потому, что я не могу поверить, что у такой распространенной проблемы нет решения. Я надеюсь, что здесь волшебники просветят нас ... @Alnitak.