Subj : Candidates vision request
To : Markus Reschke
From : mark lewis
Date : Sun Dec 09 2018 10:28 am
On 2018 Dec 05 21:10:56, you wrote to Carol Shenkenberger:
CS>> What standards do you show to represent when a site has 2 resolving
CS>> addresses, one preferred for IBN but the other for everything? Z1
CS>> practical resolution, yet another thing not documented. The world is
CS>> not black and white.
MR> Putting on my software developer hat, I'm quite unhappy with such
MR> undocumented features.
what undocumented features? IIRC, binkd was the first to offer this
capability... you can easily list multiple semicolon separated domains in the
NODE lines...
MR> I've written a small tool to extract the binkp nodes from the
MR> nodelist. The FTSC documentation states that the IBN flag should carry
MR> a FQDN/IP when binkd is accepting calls only on that FQDN/IP and it's
MR> different from the FQDN/IP in the INA flag. Or in other words, the
MR> FQDN/IP in the IBN flag prevails and no other address should be called
MR> by binkd.
that's now how binkd works... it cycles through the presented domains...
MR> In your case the tool would take just shenks.dyndns.org as explained
MR> above. But with the undocumented feature I would have to add a special
MR> case which also takes shenks.synchro.net as second address.
binkd (and argus/radius/taurus) nodelist tools do this without any problem... i
remember when Jerry Schwartz was writing the binkd_nodelister.pl script and
how he asked questions of the FTSC about this very thing with multiple domains
in a nodelist line... it was decided at that time to list all the domains found
in the specified fields and write them in a semicolon separated list to the
binkd configuration file like binkd worked with... other nodelist convertors
would list the multiple domains in a manner consistent with the mailer(s) they
support... if the mailer doesn't have support for multiple domains, then the
convertor tool would choose the proper one for that mailer...
MR> The big problem is that I can't know which nodelist entry follows the
MR> FTSC docs and which one follows the undocumented feature. To resolve
MR> this delemma we would need a new flag indicating which method applies
MR> (standard or undocumented feature). Or we could simply follow the FTSC
MR> documented standard.
this additional flag thing is overengineering... it isn't needed... mailers use
the available domains listed in the specified nodelist fields... they've done
this for a long time... i tested argus/radius/taurus with multiple domains and
also POTS and they cycled through each domain and the POTS until a connection
was made... binkd does the same except that it doesn't do POTS...
MR> These are things we have to take into account when creating zone
MR> specific special features. They can lead to unexpected results. In
MR> this case no nodelist-to-binkd converter is able to extract the
MR> correct addresses because there is no way to figure out which
MR> "standard" was used for a specific node.
really??? these 81 multiple domain entries from BINKD.TXT would seem to
disagree with you...
the distributed ARGUS.TXT also has multiple domain entries but that convertor
script seems to miss the INA entries... maybe it is protocol oriented so it
only works with the domains attached to an IP flag?? if that's the case, it
also misses the entries with the domain in the system field (not attached to a
flag) as well as those attached to the INA flag... i don't know for sure as
i've not used the convertor that scott little uses to create said distributed
file... scott would have the answer as to why argus.txt has different output
than binkd.txt...
Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... In the beginning there was nothing, which exploded.
---
* Origin: (1:3634/12.73)
