every 30 seconds??

[mark lewis]

binkd/1.0.0/OS2

why is binkd performing DNS lookups every *30 seconds* on fidonet addresses
that are not listed in binkp.net... every lookup results in NXDOMAIN-IPv4 for
them... does it not believe the answer it gets?

how do i know? i see them in my DNS logs...

)\/(ark

[Andre Grueneberg]

Hi mark

mark lewis schrieb:

ml> why is binkd performing DNS lookups every *30 seconds* on fidonet
ml> addresses that are not listed in binkp.net... every lookup results
ml> in NXDOMAIN-IPv4 for them... does it not believe the answer it
ml> gets?
ml> how do i know? i see them in my DNS logs...

Didn't we have the discussion a while ago? Getting an NXDOMAIN is nothing bad
and why should an application cache the name resoltion results. This is the job
of the (stub-)resolver.

CU Andre E-Mail: ***@grueneberg.de

[mark lewis]

ml> why is binkd performing DNS lookups every *30 seconds* on fidonet
ml> addresses that are not listed in binkp.net... every lookup results
ml> in NXDOMAIN-IPv4 for them... does it not believe the answer it
ml> gets?
ml> how do i know? i see them in my DNS logs...

AG> Didn't we have the discussion a while ago?

yes, somewhat...

AG> Getting an NXDOMAIN is nothing bad and why should an application
AG> cache the name resoltion results. This is the job of the
AG> (stub-)resolver.

one of the "problems" (as it were), is lookups being done every 30 seconds...

another of the problems is the traffic generated... i'm very happy that i do
not have to pay for bytes transferred (metered connection) but others do...

and finally, there's the question of why even perform DNS lookups on the AKAs
presented... what purpose does it serve??

)\/(ark

[Andre Grueneberg]

Hi mark

mark lewis schrieb:

ml> another of the problems is the traffic generated... i'm very happy
ml> that i do not have to pay for bytes transferred (metered
ml> connection) but others do...

Why don't you use a caching resolver on your side of the connection then? DNS
doesn't generate that much traffic.

ml> and finally, there's the question of why even perform DNS lookups
ml> on the AKAs presented... what purpose does it serve??

It's done during outbound scan. You may increase the outbound scan interval and
obviously you can disable binkp.net usage at large and only use locally
configured node entries.

CU Andre E-Mail: ***@grueneberg.de

[mark lewis]

ml> another of the problems is the traffic generated... i'm very happy
ml> that i do not have to pay for bytes transferred (metered
ml> connection) but others do...

AG> Why don't you use a caching resolver on your side of the connection
AG> then? DNS doesn't generate that much traffic.

i do but the traffic is still there for no (real and known) necessary reason...
it is via this resolver that i see all the DNS traffic from binkd...

ml> and finally, there's the question of why even perform DNS lookups
ml> on the AKAs presented... what purpose does it serve??

AG> It's done during outbound scan.

it is also done on every connection AFAICT without digging into the code...

AG> You may increase the outbound scan interval and obviously you can
AG> disable binkp.net usage at large and only use locally configured
AG> node entries.

after the message the other day, i've already removed the root-domain entry and
adjusted all of my domain entries to look only to their configured domains...
and this brings us right back to my other question about limiting binkd to only
lookup addresses in the domains i have configured...

for example: i am not in pascalnet... there is absolutely no reason for any
addresses in that domain to ever be looked up... so i asked how we are to limit
the zones that are defined for a domain so we can try to limit those lookups...

)\/(ark

[Andre Grueneberg]

Hi mark

mark lewis schrieb:

ml>> and finally, there's the question of why even perform DNS lookups
ml>> on the AKAs presented... what purpose does it serve??
AG>> It's done during outbound scan.
ml> it is also done on every connection AFAICT without digging into the
ml> code...

Which is connected. During a connection the outbound is being scanned ... for
obvious reasons.

CU Andre E-Mail: ***@grueneberg.de

[mark lewis]

ml>> and finally, there's the question of why even perform DNS lookups
ml>> on the AKAs presented... what purpose does it serve??

AG>> It's done during outbound scan.

ml> it is also done on every connection AFAICT without digging into the
ml> code...

AG> Which is connected. During a connection the outbound is being
AG> scanned ... for obvious reasons.

right... but no one has yet said why the AKAs of remote systems are being
looked up in the DNS... especially those domains/zones not configured in the
local config file... doesn't the FTN address give all the necessary
information...

)\/(ark

[Benny Pedersen]

Hello Andre!

19 Oct 2012 15:10, Andre Grueneberg wrote to mark lewis:

AG> Why don't you use a caching resolver on your side of the connection
AG> then? DNS doesn't generate that much traffic.

its irelevant to his question


Regards Benny

... there can only be one way of life, and it works :)

[Benny Pedersen]

Hello mark!

18 Oct 2012 19:52, mark lewis wrote to Andre Grueneberg:

ml> and finally, there's the question of why even perform DNS lookups on
ml> the AKAs presented... what purpose does it serve??

try nolog in binkd.cfg ?

cant remember if it defaults to resolve ip to hostname ?

show binkd.cfg will be helpfull atleast for me :)


Regards Benny

... there can only be one way of life, and it works :)

[mark lewis]

ml> and finally, there's the question of why even perform DNS lookups on
ml> the AKAs presented... what purpose does it serve??

BP> try nolog in binkd.cfg ?

why?? binkd is not doing the logging i'm discussing...

BP> cant remember if it defaults to resolve ip to hostname ?

are you prehaps thinking of "backresolv"??

)\/(ark

[Benny Pedersen]

Hello mark!

21 Oct 2012 09:36, mark lewis wrote to Benny Pedersen:

BP>> try nolog in binkd.cfg ?
ml> why?? binkd is not doing the logging i'm discussing...

if there is no loging then there is no need to make dns hostname check

BP>> cant remember if it defaults to resolve ip to hostname ?
ml> are you prehaps thinking of "backresolv"??

yes this will disbble it


Regards Benny

... there can only be one way of life, and it works :)

[mark lewis]

BP>> try nolog in binkd.cfg ?
ml> why?? binkd is not doing the logging i'm discussing...

BP> if there is no loging then there is no need to make dns hostname
BP> check

AFAICT, nolog only prevents writting to the log file...

BP>> cant remember if it defaults to resolve ip to hostname ?
ml> are you prehaps thinking of "backresolv"??

BP> yes this will disbble it

i do no have backresolv for a long time... i removed it to prevent rDNS lookups
from being logged but there are still fnz conversions being done on the
*/AKAs/* presented by the remote system and those are having DNS lookups being
done on them... these are what i'm asking about...

)\/(ark

[mark lewis]

BP>> try nolog in binkd.cfg ?
ml> why?? binkd is not doing the logging i'm discussing...

BP> if there is no loging then there is no need to make dns hostname
BP> check

ml> AFAICT, nolog only prevents writting to the log file...

correction: nolog only prevents writting to the binkd log file... but, to
emphasis again, i'm not talking about binkd logging...

)\/(ark

[Benny Pedersen]

Hello Andre!

18 Oct 2012 22:01, Andre Grueneberg wrote to mark lewis:

AG> This is the job of the (stub-)resolver.

bah :)


Regards Benny

... there can only be one way of life, and it works :)