У меня было немного вопросы с определенным поставщиком сети через неизменные серверы имен, что делает мой сайт невидимым для их клиентов. Меня бы не беспокоило то, что это один из крупнейших интернет-провайдеров в Ирландии.
Они утверждают, что записи все еще активны на старых серверах имен для моего сайта, поэтому они не должны изменяться, пока не получат ответ, сообщающий им, что для этого сайта нет записей DNS.
У меня вопрос, как правильно? Все остальные сетевые провайдеры, ISP, DNS-серверы в сети обновились до моих новых серверов имен.
Соблюдают ли они некоторые технически правильные, но игнорируемые RFC, в которых говорится, что им не нужно проверять новые серверы имен, пока старые не вернут ошибку?
Обновить:
В конце концов Vodafone связался со мной и сказал, что они решили проблему, и, что более важно, теперь передают ее своему соответствующему техническому персоналу, чтобы эта проблема не затронула никого другого. Надеюсь, это решит проблему.
Похоже, вы столкнулись с проблемой, известной как детские липкие резолверы.
Для каждого доменного имени есть два возможных набора NS записи - в родительской зоне и в самой зоне.
Некоторые рекурсивные преобразователи будут кэшировать набор, полученный от дочернего элемента, а затем многократно возвращаться на эти серверы для всех последующих обновлений. Это ребенок липкий поведение. Если записи родительской зоны изменяются, но записи (исходной) дочерней зоны остаются без изменений, эти ребенок липкий резолверы не заметят изменения в родительской зоне.
Многие (если не большинство) реализаций вернутся к родительскому NS записи, чтобы гарантировать, что они не изменились всякий раз, когда текущий NS набор записей истекает из кеша. Это считается «нормальным поведением», но в RFC не указывается однозначно.
Чтобы обойти это ребенок липкий поведение с вашей стороны, вы должны заменить NS записи на ваших старых серверах с правильными записями, показывающими имена новых серверов.
Подробнее см. Слайды с 8 по 15 документа. эта презентация Олафур Гудмундссон, председатель IETF Рабочая группа DNSEXT.
Соблюдают ли они некоторые технически правильные, но игнорируемые RFC, в которых говорится, что им не нужно проверять новые серверы имен, пока старые не вернут ошибку?
Откуда нам знать?
AFAIK нет такой вещи - и они должны обновить записи каждый когда они получают запрос на кешированную запись с истекшим TTL.
Ну, я видел на ns.webfusion.co.uk записи для данных вашего домена в нем. К сожалению, вы не убивали зоны на старых NS, но это не оправдывает поведение Vodafone. Я объясню это сейчас. Что ж, допустим резолверы Vodafone некоторое время назад кэшировал обе записи: A для www и NS для домена. Но я вижу
Quering 212.67.202.1 for {cookingisfun.ie.,NS}
; Answer ID: 18467 QR: true OPCODE: QUERY AA: true TC: false RD: true
; RA: false RCODE: NOERROR qc 1 an 2 au 0 ad 2
; Question section:
;cookingisfun.ie. IN NS
; Answer section:
cookingisfun.ie. 1d IN NS ns2.hosteurope.com.
cookingisfun.ie. 1d IN NS ns.hosteurope.com.
; Authority section:
;(none)
; Additional section:
ns2.hosteurope.com. 2h IN A 92.51.159.40
ns.hosteurope.com. 2h IN A 212.67.202.2
т.е. NS-записи должны быть просрочены и удалены из кеша через сутки после получения
Quering 212.67.202.1 for {www.cookingisfun.ie.,A}
; Answer ID: 18467 QR: true OPCODE: QUERY AA: true TC: false RD: true
; RA: false RCODE: NOERROR qc 1 an 1 au 0 ad 0
; Question section:
;www.cookingisfun.ie. IN A
; Answer section:
www.cookingisfun.ie. 1d IN A 212.67.220.186
; Authority section:
;(none)
; Additional section:
;(none)
; Query took: 94 msec
; Server queried: 212.67.202.1[udp]
такой же однодневный интервал применяется к A для www.cookingisfun.ie
То есть после однодневной задержки Vodafone должен повторно спросить об A, и какой-то рекурсор на пути вернет новые NS и новые NS - новые A.
Поскольку мы знаем, что это не происходит, я рассматриваю это как сильная строка игнорирования RFC (хранение устаревших данных в кеше - см. мой ответ на ваш предыдущий вопрос). Тоби, я думаю, вы можете показать мои запросы выше в Vodafone и спросить: «WTF ??? Почему вы используете устаревшие данные? не должен спросите 212.67.202.2 о ничего не связанное с кулинарией давным-давно. Fixit ASAP »