No UDP reply if any of the listen directives (<main>) is used on FreeBSD-13

[gh-ix]

Hello,

as soon as I configure the "listen" or "do-not-listen" directives, hence yadifad(8) is not binding to *:53, UDP queries aren't answered anymore. Only TCP replies work with yadifa 2.4.2 on FreeBSD 13 in that case.
UPD queries get logged, but no answer is sent by yadifad.
If yadifa utilizes IP_BINDANY after removing "listen" resp. "do-not-listen" from the

configuration, UDP replies work as expected.
Unfortunately limiting listening IPs is a prerequisite in my environment/use case, but time and skills are limited to debug myself.

[yadifa]

Hello,

Thank you for reporting this issue.
There was an issue sending UDP messages through specifically bound interfaces on FreeBSD.
The issue has now been fixed internally and the code should be committed next Monday.

[gh-ix]

I'd like to kindly ask for the fix to be published. This issue stopped my evaluation and time on this is very limited, yet I'm very interested in getting yadifad(8) onto my approval list. Thanks, -harry

[yadifa]

Hello, sorry for the delay.
We have just pushed the fix to the master.

[gh-ix]

Thank you very much!
After some brief testing I can confirm that I get UDP replies still after setting a "listen" directive in the config file on FreeBSD 13 and yadifa/2.4.3-10039.

Unfortunately, there's one oddity left:
TCP replies show query times between 40ms and 4000ms.
I noticed a TCP-only reply delay during my first test with version 2.4.2 too.
But I think it's worse with 2.4.3-10039, since a can't remeber much more than 100ms with version 2.4.2 (unfortunately no environment to backcheck).

Shall I file an extra issue here at GH?

Thaks, -harry
P.S.: Did a q'n'd dns/yadifa-devel port for FreeBSD, if someone want's to compile 2.4.3-10039 (pre-release) I'm happy to provide on request.

[gh-ix]

svrtcp50 | server | E | tcp: 169.254.0.53#56853: loop 1: length prefix not received after 3.141s: TCP_RATE_TOO_SLOW
This is the only hint I found for the TCP delay issue. Late here, no power left for tcpdump(1), but could try to find some time next weekend if somebody was interested in frame flow.

[yadifa]

We have also noticed the delayed answer issue on our side, the TCP_RATE_TOO_SLOW is a consequence. We think we have a fix and plan to push it today or tomorrow.

[yadifa]

After testing, the fix doesn't solve the issue on every tried case. Consequently its release has been postponed.
We are sorry for the inconvenience.

[yadifa]

We just have pushed the corrected fix on the master branch.
The build needs to be configured using --enable-tcp-manager
(see ./configure --help)

With this option enabled, there are new settings available:

<main>
max-secondary-tcp-queries 16 # the maximum number of concurrent TCP queries for a known host (e.g.: secondaries and the server itself)
</main>

At the moment, unknown hosts are allowed only 1 TCP query at a time.