Good ${greeting_time}, Michiel!

06 Oct 2014 15:47:24, you wrote to mark lewis:

 MvdV>>> That is a nono. After the folding of fidonet.net the Fidonet
 MvdV>>> community realised that depening on a third party over which
 MvdV>>> Fidonet has no control is a bad idea.
 ml>> that's fidonet... other FTNs do use such and there is the binkp.net
 ml>> which is used by default by a very widely used mailer...
 MV> If you mean binkd, no it is not. Perhaps you mean that it is enabled
 MV> in the sample configuration file that comes with it. Do not use * in
 MV> the host list of the node and defnode keywords and it will not use
 MV> DNS distibuted nodelists.

The "*" as the hostname and root-domain parameter are primarily intended for
single connections (like sending direct netmail when routing doesn't work).
Permanent links should (in the meaning from FTA-1006: do that, unless you have
really strong reasons for not doing) be explicitly configured to use all known
information: all hostnames from nodelist and, possibly, literal IP addresses
(just in case of DNS failure or domain expiration).

For example, your node is listed in my binkd.links as:

node 2:280/5555 fido.vlist.eu;2001:7b8:2ff:3a9::2;83.82.233.201 [password]

That means, my node will try to resolve fido.vlist.eu first (as this hostname
appears in the nodelist), but if that fails, it will try both IPv6 and IPv4
addresses (once known to be static).

 MvdV>>> The nodelist is the primary source of Fdionet connection
 MvdV>>> information. All the information to make a connection MUST
 MvdV>>> be present in the nodelist. DNS distributed nodelists as
 MvdV>>> documenetd in FTS-5004 are an /additional/ service, not a
 MvdV>>> replacement for the nodelist.
 ml>> agreed on both accounts...
 MV> So a protocol flag without an associated host name or IP number
 MV> in the nodelist is an error.

As FTSC, we should point ZCs at this error...

 MvdV>>> It is a mystery to me why anyone would compose such an exotic
 MvdV>>> system.
 ml>> connection limitations is one of the first that come to mind...
 ml>> in the original example, site3 was to be a final backup if the
 ml>> others could not be reached...
 MV> You know, you don't HAVE to list all your connections in the
 MV> nodelist. It is not a MUST. All that is required is that you list
 MV> /a/ connection method that will let others connect to you. This
 MV> is an amateur network. No one will hold it against you if you can
 MV> not offer 100% connectivity.

Hmmm... I'm about to reach 99.995% - less than 2 months left. And reaching
99.999 is on my agenda :-)
Well, as a HL/HA system architect I have both knowledge and ability for that
(main server is rented, backup server is at my home).

 MV> It is OK to only publish the more obscure connectiom methods to a
 MV> limited number of selected parties.

Once I tried FTN connection over binkp over tcp over AX.25 over UHF radio.
However, that's not the connection method I'd like to publish in the nodelist.

 MV> In fact here this was not unusual in the POTS age. Several nodes/BBSs here
 MV> in The Netherlands had two telephone lines. But only one of the numbers
 MV> was published in the nodelist. The other number was only given to
 MV> preferred users/points. The second line did not need to observe ZMH of
 MV> course. So users could continuue to be served all night.

Another option was to use these hidden lines for outgoing connections.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin.ru!gremlin; +vii-cmiii-ccxxix-lxxix-xlii

... god@universe:~ # cvs up && make world
--- /bin/vi