Не помню чтобы я их прямо часто использовал

Единичные случаи. А TXT под всякие DKIM/SPF/DMARC часто

Зависит от того, где трудишься. SRV любит Microsoft использовать.

Для XMPP своего использовал лет 10 назад и всё

Ну и нынче по поводу изменения/расширения SRV мощный движ пошёл.

Вон Рома недавно драфт постил

Распространение префиксов по BGP контролируется политикой BGP - местной, на этом конкретном узле, к которой есть полный административный доступ, и удаленной, на другой стороне, которая может быть под другим административным управлением. Кроме ORF (Outbound Route Filtering, RFC5291 - это механизм, который может передать удаленному узлу список фильтров, которые могут быть поставлены на выходную сторону удаленного узла), не существует механизма, который позволил бы напрямую менять политику удаленного узла. Такой подход в операционных кругах является само собой понятным, и управление поведением пропагирования префиксов делается при помощи манипуляции атрибутами, как правило, согласовавшись с другой стороной, и делается это по конфигурационному каналу на локальном узле. BGP как таковой не участвует в процессе синхронизации политик.

В рабочей группе IDR в IETF, которая занимается развитием BGP, есть предложение по передаче политик BGP по самому BGP, и включительно между административными доменами - просто говоря, из одной AS можно менять политику в узлах другой AS. Звучит страшно? Это предложение идет от одного вендора, они утверждают, что эсть и реализации, и много довольных операторов, которые это используют, но при разговоре с операционным сообществом картинка получается немного иной - о таком предложении не знают, и не особенно понимают, как этим пользоваться. Это грустная реальность в IETF - вендоры пробуют делать что-то, не понимая операционных проблем и как их продукты используются, и пробуют надавить собственное понимание о том, как сеть должна работать на тех, кто этим занимается повседневно. Нужно ваше мнение об этой теме - и пока только об этой теме, так как в IETF с BGP происходит многое, и по разным темам подискутируем в разное время.

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

Описание политики стоит на моделе condition-action. Condition описывает правила, по которым префикс с атрибутами подходит или не подходит, и, если подходит, тогда над префиксом выполняются операции, описанные в action. Такое описание политик натурально отличается от формата, который использует платформа на своем собственном конфигурационном канале, и представляет часть от всех возможностей платформы. Разные платформы имеют разную функциональность, и такое останется - это взгляд каждого вендора на адресуемый рынок и их собственное понятие, что нужно этому рынку, в этом контексте бесперспективно выглядит старание изобресто один универсальный формат представления политик. В conditions есть фильтры по IPv4 и IPv6 префиксам и их длине, standard communities, и текстовый регекс по AS path. В actions есть пропагирование префикса, AS prepend с указанным значением, и модификация MED. Для дискуссии: какие операции над атрибутами вы пользуете у себя? Каких операций не хватает?

Сами политики передаются как префикс с атрибутами в новом address family, эти префиксы не подмешиваются к IPv4/IPv6. BGP является multipoint протоколом, там нет встроенных механизмов ограничивать распространение информации, и все узлы в домене дистрибуции будут получать все изменения политик всех узлов. Контроль над тем, который конкретный узел будет обрабатывать политики, назначенные для себя, делается атрибутами на префиксе политик, там указывается конкретный узел (по router-id или по адресу интерфейса). Сами атрибуты передаются при помощи контейнера атрибутов, имеющим и другое название - это wide community. Тема дискуссий о standard, extended, large, и wide communities - это для другого сочинения. :-) В контексте пропагирования политик wide communities не делает ничего особенного кроме предоставления транспорта для атрибутов.

Все это может показаться похожим на Flowspec (кстати, это еще одно сочинение). И правильно кажется, так как это предложение выросло из механизма Flowspec, как способ передачи изменения политик в качестве операции flowspec. Оно некоторое время так тихо и спокойно развивалось, и постепенно переросло в что-то с намного более развитым функционалом и другим кругом применений. Проблема в том, что операционное сообщество не знало о таких разработках и не высказало свое мнение о том, решает ли это реальные проблемы, и являются ли эти решения практически применимыми.

Сам документ - https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/

Большинство деталей там - для имплементоров, вам как операторам не особенно важно, какой бит на проводе отвечает за что, и все диаграммы и списки могут и устрашить. Чего нет в документе - это интерпретации функционала, который как раз здесь и описан.

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

Q1. Видите ли вы потребность в практическом формате описания политик роутинга, независимого от реализаций конкретного вендора? Акцент на "практический" - такой, который позволяет выразить ваши имеющиеся политики с сохранением функциональности. Это охватывает общий набор операций по соответствию и модификации атрибутов и набор точек подключения таких политик.

Q2. Видите ли вы потребность в контролировать политику не по конфигурационному каналу в объеме больше, чем это позволяет ORF?

Q3. Видите ли вы потребность в механизме управления политикой через административную границу в оба направления? Видите ли вы потребность управлять удаленным узлом? Видите ли вы потребность разрешить удаленному узлу управлять политикой на вашем локальном узле?

Q4. Подходит ли multipoint парадигма распространения информации по BGP для такого механизма?

Q5. Как вы оцениваете уровень операционной сложности такого механизма - те результаты, которые потенциально могут быть достигнуты при использовании распространения политик по BGP, оправдывают ли они свою цену потенциального полного изменения формата и методологий политик?

По-моему это очередное решето. Причем теперь источником станет любой стык.

Прочитал, пригнулся... Как разогнусь, что-то отвечу :)

Но первое, что я могу сказать: если это новая AF, которая по умолчанию разлетается куда попало, а потом мы её пытаемся ограничивать, то это пздц какой-то. Ну то есть, это:
1) Грамотно выстроить заборы для нераспространения и неприёму этой AF - отдельная сложная задача, которую надо будет решать каждый раз при изменениях в сети
2) Для классических AF - в частности, v4 и v6 - BGP как контролька задаёт правила для data plane соответствующего протокола. Data и control в противотоке, вот это вот всё (да, знаю про исключения, но это исключения). Тут мы мешаем это принцип, заведя новую AF, которая сама по себе тоже управляет не data, а control plane, но распространяется как остальные AF. Это, на мой взгляд, концептуально криво. То есть, это соответствует подходу "BGP как универсальный контейнер для всего на свете", но я не уверен, что этот подход, особенно в Интернете, с сетями под разным управлением, имеет хоть какой-то смысл.
3) Любая ошибка в этой, довольно сложной, системе, даёт огромные возможности по новым malicious вмешательствам в работу протокола BGP. В частности, по причине п.1). Мало имеющихся?
4) Я не увидел никакой сигнализации о том, принял получатель полученную  политику, или нет. Но без возможностей фильтрации и отказа в приёме этих политик риски такого накатывания политик становятся слишком опасными. Таким образом, мы имеем недетерминированную распределенную систему - политика принимается или нет, неизвестно, принимается или нет полностью или частично, неизвестно, то, что вдруг перестала приниматься - тоже неизвестно. Ну обалдеть теперь, чо. Глюки будут ловиться очень и очень тяжело и болезненно.
5) При этом передача этих политик - дело небесплатное. Насколько удлинится получение fv по BGP? Ну, если заборы расставлены всеми-всеми правильно, то нинаскол ко. Но см.п.1)
6) Flowspec сейчас в мире даёт три с половиной калеки

Для начала так.

А, и 7). Очень легко представить себе создание петель трафика с помощью такой штуки. Организационно найти, где петлю на 3, например, AS надо расцепить - будет весёлым занятием. Учитывая, что "мы свои политики не просто так написали, пусть те вон свои правят" от каждого из участников.

Потом, может, ещё напишу :)

7. С петлями там не будет так уж плохо - при передаче RPD префикса он обвешивается стандартными атрибутами, и по as-path и cluster-list можно отбросить запетлившиыеся пути. Но это мелочи при сравнении с другими проблемами.

1. AF поднимается по механизму capabilities - если сосед поддерживает, то будем слать все подряд, если не поддерживает - ничего слать не будем, это стандартное поведение всех AF без вмешательства оператора.

2. Это не первая и не последняя попытка из BGP сделать универсальный транспортный протокол для синхронизации баз данных. Главная проблема здесь - нехотение понять, что если что-то сделать можно, то не обязательно так и делать.

Но так интересно наблюдать как реагируют разные реализации dns на наличие одновременно cname и ещё A-record )