Оно задумано, чтобы клиент мог подписаться на обновления конкретных записей, т.е. это уменьшенный аналог трансфера зоны на вторичный сервер. Любой клиент в результате становится таким вторичным сервером для конкретных записей. Тут даже кеширующий сервер ни при чем. Это нужно конкретному клиенту-пользователю. Т.е. клиент приходит на авторитативный сервер и подписывается на обновления конкретных записей. Когда они изменяются, клиент на это реагирует. Это никак не связано с кешем DNS, он вообще в этом не участвует. Это такой способ уведомить клиента об изменении конфигурации, например, некоего сервиса, через авторитативный DNS.

P.S. Я почему-то подумал, что kube-DNS - это кеширующий локальный DNS на каждой ноде.

Но ведь наверняка в реализациях будет лимит на количество подписок от клиента. А может быть и время жизни для таких подписок сделают.

> 4.  State Considerations
> ...After a client establishes a session to a DNS server, each subscription is individually accepted or rejected.  Servers may employ various techniques to limit subscriptions to a manageable level...

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

> Зона обновлённая клиенту нужна тогда, когда он желает её получить.

Не принимаю за ответ, ибо не всегда мы получаем того, чего желаем. По большей части мы можем только добиваться желаемого.

Требует ли рядовой солдат полномочий генерала? - Думаю, нет, а желает ли каждый солдат стать генералом? Думаю, да.

> Дадут ему эту зону или нет - это уже другой вопрос.

Вернемся на землю, вопрос был конкретный без условностей, "если бы да кабы".

cassandra.namespace.svc.cluster.local.

вместо всей зоны.

Еще, возможно, протокол трансфера зоны не стандартизирован, а тут потребовалось стандартизировать решение.

Типичный namespace.svc.cluster.local может содержать сотни и тысячи RR, не круто каждый раз столько по сети гонять.
Ну и реализовывать в клиенте функциональность авторитативного слейва — такое себе. Опять же, ему придётся парсить всю зону ради одной-двух записей.

Перекладывать нагрузку с сервера на клиент — неплохое решение, но только при условии, что за ресурсы клиента вы не платите. В противном случае не просто получаем умножение нагрузки пропорционально числу клиентов, но и страдаем от него.

> Однако, в реальности они все-таки будут в отдельном домене, потому что придется как-то настраивать разрешения на отдачу этих данных, а это проще будет сделать для домена целиком.

Почему?

ты до сих пор не нашёл в статье слово "клиент"? этот вот новый предложенный стандарт push-уведомлений разработан для клиентов. понимаешь? поэтому всё что ты там выше написал про веками доступные уведомления об изменениях зон и передачу таковых по частям или целиком - просто не по теме, потому что это доступно лишь для серверов. грубо говоря, master-сервер уведомляет slave-сервер, slave-сервер шлёт запрос и master-сервер отдаёт ему обновлённую зону (AXFR или IXFR). здесь же речь идёт о push-обновлениях конкретных записей со стороны сервера клиенту, а не зон целиком. считать slave-сервер (как и caching resolver или просто forwarder) клиентом - грубая ошибка. клиентом может быть например javascript  работающий в броузере или некая (ещё быть может даже не разработанная) name resolution система на уровне OS, что будет принимать такие push-уведомления. включи мозг и перестань путать сервер с клиентом

По-хорошему в пределах своей инфраструктуры можно делать поллинг хоть каждую секунду, нагрузка по сути та же, даже меньше - накладные расходы у TCP не так малы.

Каков юзкейс в реальности, где TTL кешей находится в диапазоне нескольких минут?
Кому конкретно не хватает стандартного UDP-поллинга, примеры в студию?
Какие проблемы решает данный посыл, и зачем городить огород, если всё и так прекрасно работает?