My pdns authoritative receive only qtype: ANY

[youcan-hchorfi]

Hello,
i have an authoritative server with pipebackend that keeps only receiving only qtype: ANY even if i set different type with dig command.

dig command
dig @127.0.0.1 -p 5300 example.com A
dig output

root@ns3:~# dig @127.0.0.1 -p 5300 example.com A

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @127.0.0.1 -p 5300 example.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12717
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.			IN	A

;; ANSWER SECTION:
example.com.		3600	IN	A	1.2.3.4

;; Query time: 4 msec
;; SERVER: 127.0.0.1#5300(127.0.0.1) (UDP)
;; WHEN: Sun Jun 09 18:23:55 UTC 2024
;; MSG SIZE  rcvd: 56

pdns log output

Jun  9 18:23:55 ns3 pdns_server[1490748]: Remote 127.0.0.1 wants 'example.com|A', do = 0, bufsize = 1232: packetcache MISS
Jun  9 18:23:55 ns3 pdns_server[1490766]: 1490766 Received: Q#011example.com#011IN#011SOA#011-1#0110.0.0.0#0110.0.0.0#0110.0.0.0/0
Jun  9 18:23:55 ns3 pdns_server[1490766]: ->>>> qtype: SOA
Jun  9 18:23:55 ns3 pdns_server[1490766]: 1490766 Sent SOA records
Jun  9 18:23:55 ns3 pdns_server[1490766]: 1490766 End of data
Jun  9 18:23:55 ns3 pdns_server[1490766]: 1490766 Received: Q#011example.com#011IN#011ANY#011-1#011127.0.0.1#0110.0.0.0#011127.0.0.1/32
Jun  9 18:23:55 ns3 pdns_server[1490766]: ->>>> qtype: ANY
Jun  9 18:23:55 ns3 pdns_server[1490766]: 1490766 Sent SOA records
Jun  9 18:23:55 ns3 pdns_server[1490766]: 1490766 Sent NS records
Jun  9 18:23:55 ns3 pdns_server[1490766]: 1490766 Sent CAA records
Jun  9 18:23:55 ns3 pdns_server[1490766]: 1490766 Sent A records
Jun  9 18:23:55 ns3 pdns_server[1490766]: 1490766 End of data

as you can see i am getting two queries ANY and SOA, some times it only ANY.

Anyone know about this behavior please

[mnordhoff]

https://doc.powerdns.com/authoritative/backends/pipe.html

Please do read the Backend Writer’s guide carefully. The PipeBackend, like all other backends, must not do any DNS thinking, but answer all questions (INCLUDING THE ANY QUESTION) faithfully. Specifically, the queries that the PipeBackend receives will not correspond to the queries that arrived over DNS. So, a query for an AAAA record may turn into a backend query for an ANY record. There is nothing that can or should be done about this.

It likes to make ANY queries to the backend, yes. (The DNS response to the client will include the appropriate records of the appropriate types.)

[youcan-hchorfi]

Thanks for the Ref @mnordhoff.
what about the first SOA record? For every 1 dig result two received queries.
it is related to UDP & TCP listen or ipv4 & ipv6 ?

root@ns3:~# ss -tunl | grep 5300
udp   UNCONN 0      0                  0.0.0.0:5300       0.0.0.0:*
udp   UNCONN 0      0                     [::]:5300          [::]:*
tcp   LISTEN 0      128                0.0.0.0:5300       0.0.0.0:*
tcp   LISTEN 0      128                   [::]:5300          [::]:*

[youcan-hchorfi]

the answer is clear from Here
https://doc.powerdns.com/authoritative/appendices/internals.html

A DNS query is not a straightforward lookup. Many DNS queries need to check the backend for additional data, for example to determine if an unfound record should lead to an NXDOMAIN (‘we know about this domain, but that record does not exist’) or an unauthoritative response.
Simplified, without CNAME processing, wildcards, referrals and DNSSEC, the algorithm is like this:
When a query for a qname/qtype tuple comes in, PowerDNS queries backends to find the closest matching SOA, thus figuring out what backend owns this zone. When the right backend has been found, PowerDNS issues a qname/ANY query to the backend. If the response is empty, NXDOMAIN is concluded. If the response is not empty, any contents matching the original qtype are added to the list of records to return, and NOERROR is set.
Each of these records is now investigated to see if it needs ‘additional processing’. This holds for example for MX records which may point to hosts for which the PowerDNS backends also contain data. This involves further lookups for A or AAAA records.
After all additional processing has been performed, PowerDNS sieves out all double records which may well have appeared. The resulting set of records is added to the answer packet, and sent out.
A zone transfer works by looking up the domain_id of the SOA record of the name and then listing all records of that domain_id. This is why all records in a domain need to have the same domain_id.
If no SOA was found, a REFUSED is returned.