Text 12945, 140 rader
Skriven 2022-09-16 18:39:54 av Pavel Gulchouck (2:463/68)
  Kommentar till text 12944 av Oli (2:280/464.47)
Ärende: FTS-5004
================
Hi Oli!

15 Sep 22, Oli ==> Pavel Gulchouck:

 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.

DNS zone is well-known term (https://en.wikipedia.org/wiki/DNS_zone), and "DDN
NS zone" is definitely not "set of records in DNS zone".

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> (translated by
https://www-binkp-net.translate.goog/faq.html?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_pto=wapp)


 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)