AV> FTS-5004 явно указывает на нежелательность публикации таких адресов в нодлисте. В норме, такие адреса не должны проходить AV> проверку на уровне NC и RC.
Уж сколько раз это обсуждали и объясняли, даже FAQ написал (https://binkp.net/faq.html) - всё без толку. :-(
Попробую ещё раз.
binkp.net состоит из трёх составляющих. 1. ddn.binkp.net - обычный классический DDN, построенный по нодлисту. 2. node.binkp.net - адреса, явно заданные сисопами через web-интерфейс. 3. dyn.binkp.net - динамические адреса узлов, полученные от поллинга 2:463/68.168, для узлов, пользующихся этим сервисом.
Базовая зона binkp.net является объединением этих трёх частей, и таким образом наиболее удобна для использования в качестве root-domain, потому что содержит всю ту информацию, что есть в DDN (т.е. в нодлисте), и, возможно, дополнительную информацию из node.binkp.net и dyn.binkp.net, если сисопы её по какой-то причине не внесли в нодлист.
Очевидно, если в нодлисте прописать адрес из binkp.net, не указав его явно на сайте https://binkp.net и не используя сервис динамических адресов, получится ровно то же самое, что если указать в нодлисте любой другой отсутствующий хост, например, f68.n463.z2.google.com или buka.happy.kiev.ua. Адрес такого узла будет неизвестен, и узел, соответственно, не будет доступен по IP. Но использовать в нодлисте адрес из зоны binkp.net, который туда попал из node.binkp.net или dyn.binkp.net, ничем не плохо и не опасно, а во многом удобно.
Теперь конкретно про FTS-5004.
===== Dependence on an individual to maintain the domain registration is a weakness of the DDN system, therefore it is strongly recommended that implementations that make use of a DDN service allow the user to easily configure the root domain and to configure overrides for often used stationary links so that these links won't be lost when the DDN service is interrupted or discontinued. =====
Это, вроде бы, не имеет никакого отношения к binkp.net, т.к. он не является DDN.
===== If the INA flag (or any of the protocol flags) of any node carries host name built from the FTN address using DDN or any other method, that node MUST be skipped and MUST NOT appear in resulting NS zone. In general, such names SHOULD NOT appear in the nodelist. =====
А вот это гораздо интереснее. "host name built from the FTN address using DDN or any other method".
Допустим, Вася Пупкин сделал dyndns-сервис для фидошников на своём домене pupkin.org. Разрешает любому фидошнику бесплатно регистрироваться, и по определённому событию (поллинг по FTN или как иначе - неважно) обновляет информацию об узле в своей зоне. И для узла, скажем 2:5098/12 появляется dyndns-хост f12.т5098.z2.pupkin.org, который сисоп Петя прописывает в INA и радуется жизни.
Тут внезапно оказывается, что кто-то не может с Петей связаться. Разбор приводит к тому, что этот кто-то использует DDN, построенный скриптом Гремлина, и в этом DDN отсутствует информация о петином узле. А на багрепорт приходит ответ, что этот FQDN f12.n5098.z2.pupkin.org построен на основании FTN-адреса 2:5098/12, и потому FTS-5004 предписывает не включать его в DDN.
Офигеть. Ну ладно, для обхода этой странности Вася меняет алгоритм и делает FQDN вида 2.5098.12.pupkin.org. Виссарионов, видя это, на основании собственной фразы в FTS "or any other method" исключает и такие адреса из DDN. Вася сдаётся, и в своём сервисе у сисопа требует явно ввести поддомен для *.pupkin.org. Петя, видя такое дело, пробует получить для своего узла petia.pupkin.org и petya.pupkin.org, оба эти имени оказываются уже занятыми, и он выбирает f12n5098.pupkin.org. Что делает Гремлин? В очередной раз подправляет скрипт, решив, что f12n5098 построен из FTN-адреса 5098/12, и опять исключает этот адрес из DDN.
В итоге видим, что Вася стремится сделать удобный и бесплатный сервис для фидошников, Петя хочет этим сервисом воспользоваться, а FTSC в лице Виссарионова путём мелких пакостей мешает им это сделать.
Именно такая ситуация сейчас есть с сервисом динамических IP в binkp.net, но шаги по изменению hostname c вида fFFF.nNNN.z2 на какое-то другое (пока?) не делались. Всё же надеюсь на благоразумие FTSC и исключение этого абзаца из следующей ревизии FTS-5004. А хорошо бы ещё и вернуть FSP (и сделать из него FTS) про флаги DOM/DO[1-4], коль уж они оказались удобными и до сих пор используются в нодлисте и в софте.