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
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.
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)
