DNS: 2 NS testing - как

>Теоретически, если упал один неймсервер, то днс ответы будет отдавать другой

практически, процентов 70% запросов к домену будут потеряны

Чего то я ночью торможу. Почему 70% а не половина?

По теме. Для делегации зоны достаточно указать NS записи и, обычно, glue-records. То есть на третей машине в описании зоны com создается NS записи для porvider.com и A записи для ns1.provider.com и ns2.provider.com. Хотя можно и через stub-зону.

Ага. Ок.
И есчё вопросец. А будет ли это корректно для provider.com назначить маленький период обновлений - типа 20 секунд например?
Цель: если мониторилка обнаружила, что, скажем ns1 сдох - то делается динамическая смена айпишника ns1 на айпишник ns2, пока не подымется сервис? В итоге легковесная колхозная альтернатива в неком роде heartbeat'у для днс - чтобы не подменять айпишников.
Конечно понимаю, что есть масса криво кеширующих серверов, которые не подхватят так быстро изменение, но всё же, как полумера - годится ?

Думаю, что это особо не поможет, точно не знаю, но вроде кешируется NS запись по TTL, задаваемой тем, кто делегировал зону. То есть .com сообщает, что за вашу зону отвечает ns1.provider.com и ns2.provider.com. И их ip-адреса.

Если в .com была бы прописана stub-зона, то тогда маленький TTL поможет (наверное). Но насколько я знаю, у тех, кто держит домены верхнего уровня stub зоны не используются. Может подумать об использовании сторонних вторичных DNS-серверов?

неа. сторонние как-то отложим. как минимум, что бы не мешать обучающему процессу.
Выходит, что наиболее оптимальный вариант, это использовать мигрирующий IP ?

т.е. переносить айпишник с упавшей днс на живую и релоадить mydns

хотя релоад - это я погарячился. простенькое провило в файрволе - и ничё не нада пелоадить