Subj : FTS-5004
To   : Pavel Gulchouck
From : Oli
Date : Thu Sep 15 2022 10:50 am

Hi Pavel,

Pavel wrote (2022-09-04):

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

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

I'm not sure ic.ddn would count as a DDN record, because it's not in the f*.n*.z*.ddn namespace. TXT records are also not covered by FTS-5004.

PG> I do not see any reasons for this limitation and propose to remove it.

I believe the idea of that restriction is, that a DDN should not deviate from the "world nodelist". Not sure what a "DDN NS zones" is supposed to mean.

PG> 2. Following paragraph seems strange and harmful:
PG> ===
PG> If the INA flag (or any of the protocol flags) of any node carries
PG> host name built from the FTN address using DDN or any other method,
PG> that node MUST be skipped and MUST NOT appear in resulting NS zone.
PG> ===
PG> It's technically impossible to detect, was hostname built from the FTN
PG> address using "any other method" (such as concatenation, crc, hash etc)
PG> or not. And I see no reasons why such hostnames should be skipped. This
PG> limitation makes DDN unusable because not all nodes with published IP
PG> address will be accessible using the DDN. I propose to remove this
PG> paragraph from the FTS.

I'm not even sure what they tried to express with this paragraph.

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

Yes, there should be only hostnames in the nodelist that do resolve properly to the IP of the node. But that is something the sysops, the *Cs and the nodelist software are responsible for. If there would be something like

Hub,545,G_from_K,M,A_V,-Unpublished-,300,IBN:f545.n5020.z2.ddn.binkp.net

in the nodelist, the harm would already be done. CNAME recursions can happen anyway and any DNS client and server should be able to handle it.

PG> As an example, there is domain node.binkp.net which allows any fidonet
PG> sysop to specify or change address of his node with web interface (with
PG> authorization by fidonet netmail). Also there is domain dyn.binkp.net for
PG> dynamic IP nodes which set IP by binkp-protocol poll of some system
PG> address. These are free services for fidonet sysops that worked for many
PG> years (more than 10). But using of this services are forbidden by
PG> FTS-5004, and I think this was one of target for this FTS.

The binkp FAQ says:

It is convenient to use the binkp.net domain as the root-domain for binkd (any DDN is also suitable for this role).
There are subdomains:
ddn.binkp.net - information from the nodelist (and only it);
node.binkp.net - addresses of nodes explicitly specified via http://binkp.net;
dyn.binkp.net - dynamic IPs.
The main binkp.net zone contains a collection of information from these three sources.

(translated by https://www-binkp-net.translate.goog/faq.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_pto=wapp)

So anyone is free to use ddn.binkp.net as a standards compliant DDN. I don't see how FTS-5004 can forbid anything that doesn't even claim to be DDN.

PG> Alexey Vissarionov now insists that using binkp.net by some sysops is XAB
PG> because this violates the FTS.

Like the existence of the Ukraine is extremely annoying for some Russians?

Is it also XAB if I remove all Russian nodes from the NODELIST and offer it as NORUSNDL?

Why I am not free to use the method of IP look up that I prefer?

I mean there are DNS services that blocks lookups of malicious host names or porn sites.

PG> Moreover, sometime (many years ago) he
PG> mentioned as an argument agains binkp.net that this service is supported
PG> by ukrainian (and Alexey is russian) and even threatened to make DDoS
PG> attack to all NSs of binkp.net for thraw this service down (he repeated
PG> this threat several days ago in sysops echo).

Alexey can go and violate Putin's dick or join Special Operation Cannon Fodder.

Btw, does he embed DDoS bots in the software he offers at
download.binkd.org
download.golded.org
download.huskyproject.org
? ;-)


PG> What do you think about this?

What I find problematic is that binkd does use binkp.net as the default root-domain. And that you always will have outdated node records. Sysops find the binkp.net website, register, put something in the DB and than forget about it. Then one day the hostname in the nodelist gets changed, and the one in [node.]binkp.net is outdated. ddn/node/dyn.binkp.net is great, binkp.net only creates more problems.

---
* Origin: War is Peace. Freedom is Slavery. Ignorance is Strength. (2:280/464.47)

You are viewing proxied material from vert.synchro.net. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.