Text 12944, 127 rader
Skriven 2022-09-15 10:50:12 av Oli (2:280/464.47)
  Kommentar till text 12942 av Pavel Gulchouck (2:463/68)
Ärende: FTS-5004
================
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.