Если сервер authoritative, он никогда не будет держать в кэше элементы
этой зоны, так что не уверен насчет выводов.
А есть вот что: CNAME *глючит* на каких-то DNS'ах (не выяснено каких
именно). Мы в своё время хотели сделать зеркало на CNAME'ах:
ставишь www.ukr.net как CNAME www.vdns.ukr.net, а там уже вьюшки. Какой
был ээфект: вместо того, чтобы выдавать своим клиентам честно
отработаный CNAME в 2 захода они получали IP адрес ns.vdns.ukr.net,
который был IN NS для vdns.ukr.net (а у них соотв. были разные IP адреса
с www-). Естествено мы сначала оттестировали из разных сетей, как оно
себя ведет в разных вьюшках, всё пучком, перепроверили, а потом на
DNS'ах начался всплеск www активности ;)
В итоге отказались от этой затеи и сделали "правильное" делегирование.
-------- Original Message --------
Subject: [uanog] [fwd] CNAME and OTHER data error
From: Valentin Nechayev
Сегодня ошибка повторилась. named-checkzone ошибок не обнаружил, а зона отказалась подхватываться при reload. После рестарта named подхватилась.
Кажется, удалось разобраться в механизме возникновения проблемы. Редкое стечение обстоятельств.
1. Зона foo.tomsk.ru делегирована. 2. В зоне foo.tomsk.ru была ошибка - действительно присутствовала CNAME запись наряду с SOA и прочими. 3. Сервер, обслуживающий зону tomsk.ru, является также рекурсивным для некоторых клиентов.
Поэтому при запросе от клиентов насчет foo.tomsk.ru CNAME запись попадала в кэш, а при перезагрузке зоны tomsk.ru данная запись конфликтовала с имеющимися в зонном файле NS записями про зону foo.tomsk.ru.
Мораль даже не знаю какая. Наверное, всегда разделять авторитетные сервера и рекурсивные сервера для клиентов (не допускать п.3).
=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message