@jack9603301 bumping tasks won't make it faster - it usually has the opposite effect

In T2486#64335, @jjakob wrote:

Also, this is reproducible with pdns-recursor from upstream master (4.4.0) so upgrading won't help.

Latest rolling runs PowerDNS recursor 4.3 T2470

Although I wanted to try it out, it seems the best way is to try to upgrade to the latest stable version. From the perspective of version management, the higher version often fixes some existing bugs, while the stable version ensures sufficient testing to avoid 0days.

@jjakob I'm sorry, but I think you may have misunderstood me. I just summarized the problems that can be solved at present. Of course, this patch can finally be submitted to PDNS. Relatively speaking, the current solution to the problem may be the first priority, and there are only two main ways to solve the problem, either to solve it or to bypass it.

In T2486#64339, @jack9603301 wrote:

I can summarize the following solutions, and maybe there are other solutions:
a) Fix the bug yourself
b) Use other storage mechanisms to resolve records to bypass
c) Self parsing hosts

If you mean we should maintain our own fork of powerdns, I'm against that. PowerDNS is open source and anyone can submit patches to it the same as VyOS. If you want to try fixing the bug in pdns-recursor, you can clone pdns, debug it, build it, test it and submit the patch at https://github.com/PowerDNS/pdns . Of course you have to oblige by their contribution guidelines that are listed there. They also have a IRC channel at OFTC #powerdns .

I can summarize the following solutions, and maybe there are other solutions:
a) Fix the bug yourself
b) Use other storage mechanisms to resolve records to bypass
c) Self parsing hosts

Alas, it's really a troublesome problem. If it's a bug, I haven't used pdns-recursor. I usually use ISC bind, but I have a solution different from the one you put forward. It is based on the independent maintenance of open source branches, looking for the code with problems and implementing the patch. @jjakob

You mean that when pdns-recursor recursively forwards the request to the back-end recursive parsing service, the static entries in the query / etc / hosts will always return NXDOMAIN?

You mean that when pdns-recursor forwards the query to the back-end recursive parsing service for the first time, after that, the static entries in query /etc/hosts will always return NODOMAIN.

The full description and way to reproduce is at https://github.com/PowerDNS/pdns/issues/9136 since this is a pdns-recursor bug. But in essence, after pdns-recursor startup or restart, requests that come in to pdns-recursor (service dns forwarding in VyOS) for a domain from /etc/hosts work normally. Then a request for any other domain comes in, that gets forwarded via forward-zones-recurse (service dns forwarding name-server), for example google.com, that request gets resolved without errors, but causes this bug to manifest. After that, a request for any hostname from /etc/hosts returns NXDOMAIN.

via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone

This is a 1300 byte ping running through a MACsec connection with wpa_supplicant for key management.

Just to confirm, increasing the route,max_size fixed this issue completely. I think it can be closed. But maybe we should set these settings by default before closing this.

Tested on 1.3-rolling-202005210117, works properly

I think the way to do this is in src/conf-mode/interfaces-ethernet.py in apply(), don't change the interfaces mac if eth['is_bond_member'] is set.

This PR419 should take care of this and the parent task

@richardpowellus you could test it on an 1.2.5 system by running the following commands:

related to T2088 where performance is also being discussed.