Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции FTSC_PUBLIC
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции FTSC_PUBLIC с датами от 13 Sep 13 18:57:24 до 01 Apr 24 01:17:44, всего сообщений: 7124
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 6518 из 7124 ====================================== FTSC_PUBLIC =
От   : Pavel Gulchouck                  2:463/68           04 Sep 22 18:46:42
Кому : All                                                 04 Sep 22 18:46:42
Тема : FTS-5004
FGHI : area://FTSC_PUBLIC?msgid=2:463/68+6314e8e2
= Кодировка сообщения определена как: CP1125 =================================
Ответ: area://FTSC_PUBLIC?msgid=2:280/464.47+6322f552
==============================================================================
Hi All!

Some points in FTS-5004 seems to me ungrounded and unusable.

1. In my oppinion the first and main target for DDN is possibility for IP mailers to connect fidonet nodes using DNS resolving.
This may be implemented by public or private (local) DNS-zone build by nodelist (DDN).
Sometimes it's convenient to add additional information such as IP-addresses of points or short hostnames (aliases), such as "ic.ddn" as cname to "n0.n2.z2.ddn" or TXT comments or some other info. But FTS-5004 forbids such cases:
===
The only valid source for DDN records is FTS-5000 world nodelist.
Data from partial (network etc.) segments SHOULD NOT appear in
DDN until they get into world nodelist. Data from any sources
other than nodelist MUST NOT appear in DDN NS zones.
===
I do not see any reasons for this limitation and propose to remove it.
This extends definition of "DDN": many DNS zones that are not DDN according to the FTS (because contain additional info) are DDN actually, because thay automaticlly built by nodelist and contain all information about IP-addresses from the nodelist.

2. Following paragraph seems strange and harmful:
===
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.
===
It's technically impossible to detect, was hostname built from the FTN address using "any other method" (such as concatenation, crc, hash etc) or not.
And I see no reasons why such hostnames should be skipped.
This limitation makes DDN unusable because not all nodes with published IP address will be accessible using the DDN.
I propose to remove this paragraph from the FTS.

3. "In general, such names SHOULD NOT appear in the nodelist".
I agree that hostnames from DDN domain is not suitable for nodelist, this makes infinite recursion.
But if the domain is not DDN, that it's fully correct to specify hostname built from my FTN address in my private domain or in public dyndns service as my hostname. It's clear and convenient.
I propose to change this sentense to "Hostnames from DDN zones SHOULD NOT appear in the nodelist" (or even "MUST NOT"), but do not forbid adding hostnames built from FTN address by "any method" if the address was configured explicitly in this domain and it's not DDN.

As an example, there is domain node.binkp.net which allows any fidonet sysop to specify or change address of his node with web interface (with authorization by fidonet netmail). Also there is domain dyn.binkp.net for dynamic IP nodes which set IP by binkp-protocol poll of some system address. These are free services for fidonet sysops that worked for many years (more than 10). But using of this services are forbidden by FTS-5004, and I think this was one of target for this FTS. Alexey Vissarionov now insists that using binkp.net by some sysops is XAB because this violates the FTS.
Moreover, sometime (many years ago) he mentioned as an argument agains binkp.net that this service is supported by ukrainian (and Alexey is russian) and even threatened to make DDoS attack to all NSs of binkp.net for thraw this service down (he repeated this threat several days ago in sysops echo).

What do you think about this?

              Lucky carrier,
                           Pavel
                           aka  gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5-b20160827
* Origin: Lucky Carrier BBS (2:463/68)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.054650 секунды