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>> ===
Ol> 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 Ol> FTS-5004.
FTS-5004 specifies contents of a DNS zone for being DDN. And according to this FTS no records other than generated from the nodelist should appear in the zone. Formally even SOA record violates this FTS, and I think this should be fixed to allow additional information which may be useful. Alexey (author of this FTS) told that DNS zone which contains additional information (such as IP addresses of points) is not DDN according by FTS-5004.
PG>> I do not see any reasons for this limitation and propose to remove it.
Ol> 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 Ol> supposed to mean.
May be, we can change this paragraph to something like "DDN MUST contains all information about IP addresses from the world nodelist and MUST NOT modify this information. DDN CAN contain information from other sources (pointlists, fresh network segments etc) only in addition to information from the world nodelist".
The idea is that official nodelist issued only weekly (I know about daily nodelist, but FPD specified weekly), and update nodelist information sometimes can takes a time. NC can be on vacation or some other delays. But DNS gives possibility to update IP address quickly, for hours or minutes, and automatically. It's dumb to disable such possibility.
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.
Ol> I'm not even sure what they tried to express with this paragraph.
They tried to forbid binkp.net as a service where any sysop can add IP address for their node even if binkp.net will use another method for generating hostname by FTN address. But they can not specify explicit service "binkp.net" in standard (and the service can be started on another domain), so they specify some secondary properties of this service. Like "featherless biped with nails" as specification of human.
[...] Ol> The binkp FAQ says:
Ol> It is convenient to use the binkp.net domain as the root-domain for binkd (any DDN is also suitable for this role). Ol> There are subdomains: Ol> ddn.binkp.net - information from the nodelist (and only it); Ol> node.binkp.net - addresses of nodes explicitly specified via http://binkp.net; Ol> dyn.binkp.net - dynamic IPs. Ol> The main binkp.net zone contains a collection of information from these three sources.
Ol> 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 Ol> claim to be DDN.
If a sysop creates a record in binkp.net zone, for example f68.n463.z2.node.binkp.net, then adding INA:f68.n463.z2.binkp.net or INA:f68.n463.z2.node.binkp.net to nodelist violates FTS-5004: "host name built from the FTN address using DDN or any other method ... SHOULD NOT appear in the nodelist" even though neiher node.binkp.net nor binkp.net are not DDN. And this is absurdity.
PG>> Alexey Vissarionov now insists that using binkp.net by some sysops is XAB because this violates the FTS.
Ol> Like the existence of the Ukraine is extremely annoying for some Russians?
Ol> Is it also XAB if I remove all Russian nodes from the NODELIST and offer it as NORUSNDL?
Ol> Why I am not free to use the method of IP look up that I prefer?
Ol> I mean there are DNS services that blocks lookups of malicious host names or porn sites.
Sorry, it's not about using binkp.net by sysop in the mailer for resolve nodes. Sure, nobody can forbid it. It's about using binkp.net in INA flag in the nodelist - Alexey says it's XAB because it violates FTS-5004.
PG>> What do you think about this?
Ol> What I find problematic is that binkd does use binkp.net as the default root-domain. And that you always will have outdated node Ol> records. Sysops find the binkp.net website, register, put something in the DB and than forget about it. Then one day the hostname in Ol> 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 Ol> problems.
Good point, I agree, the problem exists. Thank you. I think I should periodically check if address specified in the node.binkp.net and ddn.binkp.net accessible by binkp protocol, and if not during some period (week or two) then remove the address and notify sysop about it. It's not hard to implement.
Lucky carrier, Pavel aka gul@gul.kiev.ua --- GoldED+/LNX 1.1.5-b20160827 * Origin: Опыт - это то, что мы получаем вместо того, что хотели (2:463/68)
