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:
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 * Origin: http://openwall.com/Owl (2:5020/545)
