Прошло много времени с тех пор, как я баловался настройками DNS, поэтому мои знания могут быть немного устаревшими.
У нас есть домен, для которого главный сервер администрируется нашей командой, а подчиненный сервер предоставляется хостинговой компанией. В какой-то момент мы решили перейти на другую хостинговую компанию. Кроме того, мы решили, что и главный, и подчиненный серверы будут администрироваться нами. В рамках подготовки к этому процессу мы уменьшили параметры обновления, повторения и истечения срока действия домена, чтобы любые изменения распространялись немного быстрее. Затем мы переместили сервер на новый хост, внесли изменения в файл зоны, подняли серийный номер и перезагрузили DNS-сервер. Процесс распространения какой-то несбалансированный. На большинстве DNS-серверов есть свежие данные. Однако некоторые этого не делают, даже если уже прошло время, установленное для истечения срока действия, и (по принуждению некоторых администраторов DNS) значение срока действия по умолчанию, равное одной неделе.
Изучая возможные причины этого, мы обнаружили, что наш сервер был неправильно настроен и разрешал запросы только от подчиненного устройства. Таким образом, в течение довольно длительного периода времени любой внешний запрос к нашему серверу завершался ошибкой, но работал с ведомым устройством. Это, конечно, было исправлено немедленно. Мы также обнаружили, что предыдущая хостинговая компания все еще имеет нашу подчиненную зону и отвечает на ручные (nslookup / host) запросы, предоставляя устаревшее представление зоны.
Итак, у меня такой вопрос: может ли старый подчиненный DNS-сервер каким-либо образом отвечать за нестабильное распространение DNS? Если какой-то DNS-сервер достигает времени истечения / обновления для какой-либо зоны, получает ли он свои данные, проходя дерево DNS полностью сверху (корневые серверы)? Или он просто проверяет сервер, с которого недавно получил информацию о зоне?
РЕДАКТИРОВАТЬ: Извините, что не упомянул это четко, но, естественно, я изменил записи DNS для домена на уровне регистратора. Если я выполняю нерекурсивные запросы с помощью nslookup / host и продвигаюсь вниз от TLD к моему домену, все согласуется с тем, что должно быть. Тем не менее, некоторые DNS-серверы предоставляют данные о старых зонах в качестве неавторизованного ответа.
Вы просто не можете исправить админов, которые отказываются слушать настройку TTL. Так что забудьте об этой проблеме, потому что ее нельзя решить.
Если предположить, что это не может быть решено, то, если вы сделали все остальные правильные шаги, вы ничего не можете сделать. Вам нужно очень постараться, чтобы синхронизировать серверы как можно лучше в маленьком окне, но даже при этом всегда есть маленькое окно, в котором мастер опережает подчиненных.
Важно то, что если вы отбрасываете подчиненное устройство, измените записи NS в зоне и измените также представление родительской зоны о записях NS. Убедитесь, что вы помните, что у вашего родителя есть копия записей NS и связанный с ними «клей» (IP-адреса) для связи с этими записями NS. Если вы не изменили представления своих родителей, это могло быть причиной ваших проблем.
DNS не распространяется. Единственный способ, которым подчиненный сервер на вашем предыдущем хосте может повлиять на разрешение имен для вашего домена, - это если он все еще указан как сервер имен для вашего домена. Проверьте информацию WHOIS для своего домена и проверьте регистратора доменов, чтобы узнать, какие серверы имен указаны для вашего домена. Если в списке указан старый подчиненный сервер, вам необходимо исправить это. Как только ваши серверы имен будут указаны как единственные серверы имен, все будет хорошо. Что касается других DNS-серверов, которые не соблюдают ваш TTL, вы ничего не можете с этим поделать. Что касается подчиненного сервера, на котором размещена зона для вашего домена, это не имеет значения, если они не являются полномочными для вашего домена.
Я могу разместить зоны DNS для Microsoft и Google, если захочу, но это имеет значение только для DNS-клиентов, которые используют мои DNS-серверы для разрешения имен. Если подчиненный сервер используется какими-либо DNS-клиентами, и если подчиненный сервер по-прежнему отвечает за ваш домен автоматически, это повлияет на разрешение имен вашего домена для этих клиентов, но это не повлияет на всех остальных DNS-клиентов.
Беги беги dig +trace NS your.domain.com затем спросите у каждого из вышеперечисленных серверов имен, что они думают о серверах имен для your.domain.com. Чтобы привести пример с att.com:
$ dig NS +trace att.com
; <<>> DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 <<>> NS +trace att.com
;; global options: +cmd
. 395258 IN NS d.root-servers.net.
. 395258 IN NS e.root-servers.net.
. 395258 IN NS c.root-servers.net.
. 395258 IN NS f.root-servers.net.
. 395258 IN NS m.root-servers.net.
. 395258 IN NS g.root-servers.net.
. 395258 IN NS l.root-servers.net.
. 395258 IN NS a.root-servers.net.
. 395258 IN NS k.root-servers.net.
. 395258 IN NS j.root-servers.net.
. 395258 IN NS b.root-servers.net.
. 395258 IN NS h.root-servers.net.
. 395258 IN NS i.root-servers.net.
;; Received 508 bytes from 212.2.96.53#53(212.2.96.53) in 213 ms
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
;; Received 497 bytes from 192.33.4.12#53(c.root-servers.net) in 190 ms
att.com. 172800 IN NS ns3.attdns.com.
att.com. 172800 IN NS ns2.attdns.com.
att.com. 172800 IN NS ns1.attdns.com.
;; Received 134 bytes from 192.48.79.30#53(j.gtld-servers.net) in 420 ms
att.com. 3600 IN NS ns1.attdns.com.
att.com. 3600 IN NS ns3.attdns.com.
att.com. 3600 IN NS ns2.attdns.com.
att.com. 3600 IN NS ns4.attdns.com.
;; Received 168 bytes from 144.160.20.47#53(ns3.attdns.com) in 210 ms
Здесь j.gtld-servers.net говорит, что серверы имен для att.com - это ns [123] .attdns.com, а ns3.attdns.com говорит, что на самом деле существует 4-й. Если вы попросите все серверы имен для com. о NS-записях для att.com. (dig NS att.com @a.gtld-servers.net. затем dig NS att.com @b.gtld-servers.net. и т. д.) у вас будет полная картина, что может получить правильно настроенный клиент, когда он запросит сервер имен для вашего домена.
Затем спросите каждый из реальных серверов имен для вашего домена (ns [1234] .attdns.com. В примере), что они думают о записях NS для своего домена (att.com в примере), и вы получите полную картину.
Это может быть немного утомительно, но если все ответы, которые вы получите, вменяемы, значит, ваша конфигурация явно верна. Вы сделали все возможное, чтобы сократить переходную фазу, и, наконец, все будет хорошо, но вы ничего не можете сделать с провайдерами, которые намеренно игнорируют TTL для записей DNS, чтобы снизить нагрузку на свои серверы.
Как уже упоминалось, другие ответы на самом деле не совсем точны. Итак, отвечая на ваш вопрос:
Может ли старый подчиненный DNS-сервер каким-то образом отвечать за нестабильное распространение DNS?
Да, может, примерно по той причине, что вы сами определили и заменили «наблюдаемые мной эффекты» на «нестабильное распространение» (чего не происходит):
Если какой-то DNS-сервер достигает времени истечения / обновления для какой-либо зоны, получает ли он свои данные, проходя дерево DNS полностью сверху (корневые серверы)? Или он просто проверяет сервер, с которого недавно получил информацию о зоне?
Помимо того факта, что люди, выполняющие запросы DNS, не загружают целые зоны, и тот факт, что время истечения срока действия / обновления не имеет к этому никакого отношения, вы думаете в правильном направлении. Людям, которые уже искали информацию DNS для вашего домена и его поддоменов, будет отправлена информация о делегировании для этого домена. Пока не будет достигнут TTL этой информации, они будут продолжать общаться напрямую с известными им DNS-серверами контента; и если они продолжат общаться с вашей старой службой хостинга DNS, им каждый раз будет сообщать старую информацию о делегировании со свежим TTL.
Этот цикл может продолжаться бесконечно. Вот почему инструкции по правильному способу переключения делегирования с одного набора DNS-серверов контента на другой, например эти инструкции и эти инструкции среди прочего, подчеркните, что важно не пропустить шаг обновление информации о делегировании, что старые серверы - все из них - опубликовать.
Вы иметь поговорить с вашей старой хостинговой компанией и заставить ее обновить то, что она публикует.