Improper handling of invalid nserver responces

[vmspike]

I use configuration with 2 nserver lines. Looks like the first nameserver occasionally replies with FORMERR, this leads to occasional unresolved domain 0.0.0.0:0 and so 00001 error (because non-public subnets are denied by configuration):

2022.02.03T00:50:09.522+0000 00001 username 203.0.113.177:54515 0.0.0.0:0 4 CONNECT www.google.ch:443 HTTP/1.1
2022.02.03T00:50:20.184+0000 00000 username 203.0.113.177:44449 18.66.216.82:443 7228 CONNECT www.amazon.it:443 HTTP/1.1

3proxy 0.8/0.9/10-master versions behaves identically, but 3proxy 0.8 also replies with 00517 error for http requests:

2022.02.03T00:50:14.380+0000 00517 username 203.0.113.177:41781 0.0.0.0:0 0 GET https://example.com/somepath HTTP/1.1

If I use /tcp suffix for the first nserver the issue is gone (if tcp is supported by nameserver).

Issuing DNS requests manually I occasionally get FORMERR:

user@hostname:~# dig -b 192.168.8.106 @192.168.8.1 -q www.google.com +short  
142.250.184.100
user@hostname:~# dig -b 192.168.8.106 @192.168.8.1 -q www.google.com +short
;; Got bad packet: FORMERR
59 bytes
11 0b 81 20 00 01 00 01 00 00 00 01 03 77 77 77          .............www
06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 01 00 01          .google.com.....
c0 0c 00 01 00 01 00 00 00 4f 00 04 8e fa b8 64          .........O.....d
00 00 00 00 00 00 00 00 00 00 00                         ...........

Adding +noedns (or +tcp if supported by nameserver) solves the issue.

user@hostname:~# dig -b 192.168.8.106 @192.168.8.1 -q www.google.com +short +noedns
142.250.184.100
user@hostname:~# dig -b 192.168.8.106 @192.168.8.1 -q www.google.com +short +tcp
142.250.184.100

It's looks that the first nameserver is buggy, but still 3proxy seems does not handle this case properly.
I'd expect 3proxy to move to the next available nserver in case of invalid DNS response (similar way it does for unavailable nameserver), or handle this case another way instead of just keeping domain unresolved.