udp6-answers Does not mean that data really was sent

[GJSBRT]

• This is not a support question, I have read about opensource and will send support questions to the IRC channel, GitHub Discussions or the mailing list.
• I have read and understood the 'out in the open' support policy

• Program: Authoritative
• Issue type: Bug report

Short description

udp6-answers	        1	Number of IPv6 answers sent out over UDP
udp6-answers-bytes	40	Total size of answers sent out over UDPv6

These counters above from the UI show that some data (I assume a packet) was sent out over UDP, however even if PowerDNS could not send data over UDP because non-local-bind is disabled for example. These counters are still incremented.

Environment

• Operating system: Linux 6.8.0-51-generic #52-Ubuntu SMP PREEMPT_DYNAMIC Thu Dec 5 13:09:44 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
• Software version: PowerDNS Authoritative Server 4.9.3 (C) PowerDNS.COM BV I also tested the latest 5.x/master release with the same result.
• Software source: Repo: deb [arch=amd64] https://repo.powerdns.com/ubuntu noble-auth-49 main

Steps to reproduce

1. Have a PowerDNS instance with a default config expect for webserver settings.
2. Make a DNS query to an IP address which is as a route on the loopback interface requiring non-local-bind to be enabled.
3. Observe a UDP DNS packet being sent but no response being received in tcpdump
4. Observe udp6-answers and udp6-answers-bytes incrementing in the UI.

Expected behaviour

I expect udp6-answers and udp6-answers-bytes to not increment if PowerDNS cannot/did not actually send data over UDP as a response.

Actual behaviour

tcpdump

$ sudo tcpdump -i any -nn -vvv 'ip6 and (udp port 53 or icmp6)'
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
12:25:37.373122 lo    In  IP6 (flowlabel 0xfb40e, hlim 64, next-header UDP (17) payload length: 61) [redacted-server]:4::3.32383 > [redacted-floating]::1.53: [bad udp cksum 0x6f18 -> 0xe70c!] 61813+ [1au] A? example.com. ar: . OPT UDPsize=1232 [COOKIE d95e8896ed6390c4] (53)
12:25:42.374188 lo    In  IP6 (flowlabel 0x663b5, hlim 64, next-header UDP (17) payload length: 61) [redacted-server]:4::3.41131 > [redacted-floating]::1.53: [bad udp cksum 0x6f18 -> 0xc4e0!] 61813+ [1au] A? example.com. ar: . OPT UDPsize=1232 [COOKIE d95e8896ed6390c4] (53)
^C
3 packets captured
7 packets received by filter
0 packets dropped by kernel

DiG

$ dig example.com A @[redacted-floating]::1
;; communications error to [redacted-floating]::1#53: timed out
;; communications error to [redacted-floating]::1#53: timed out

PowerDNS

udp6-answers	2	Number of IPv6 answers sent out over UDP
udp6-answers-bytes	114	Total size of answers sent out over UDPv6
udp6-queries	2	Number of IPv6 UDP queries received

Other information

This could all be very much correct, but it very much was not expected. It could also very well be that PowerDNS does send data but that its being dropped by the kernel, however I could not find any evidence that the kernel did drop it. Also enabling non-local-bind fixing it does not make me think that the kernel is the issue. Also I expected some kind of error when PowerDNS could not send data, but this may also be the reason that the counters in the UI are still incremented as PowerDNS thinks data has been sent. Maybe some missing error handling?

I have only tested this with IPv6.

[omoerbeek]

Looks like void UDPNameserver::send(DNSPacket& p) in nameserver.cc increments stats in all cases, even error cases. So that confirms your observation.