recursor not returning soa record of delegated zone

[gucki]

Using the pdns-recursor 4.4.2-3 package of Debian 11.

Background: I'm running a local pdns-recursor. When I tried to generate a letsencrypt wildcard certificate using the acmedns challenge it always failed with "could not determine authoritative nameserver". After spending a lot of time, the solution was to change the dns server used by the letsencrypt client to another one (for example 1.1.1.1 or 8.8.8.8). So it seems to be some issue with the pdns-recursor - which works without any issues, except in this case.

The example.com domain is configured like this:

auth.example.com.	60	IN	NS auth.example.com.
auth.example.com.	60	IN	A	1.2.3.4

The nameserver of example.com and auth.example.com are different.

dig @pdns-recursor _acme-challenge.example.com soa

; <<>> DiG 9.16.1-Ubuntu <<>> @pdns-recursor _acme-challenge.example.com soa
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25411
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_acme-challenge.example.com. IN SOA

;; ANSWER SECTION:
_acme-challenge.example.com. 60 IN CNAME 93b0b213-4946-4007-aa76-685ce2f5f760.auth.example.com.

;; AUTHORITY SECTION:
auth.example.com.	60	IN	NS	auth.example.com.

;; ADDITIONAL SECTION:
auth.example.com.	60	IN	A	1.2.3.4

;; Query time: 16 msec
;; SERVER: 10.1.2.3#53(10.1.2.3)
;; WHEN: Thu Aug 31 13:03:27 CEST 2023
;; MSG SIZE  rcvd: 158

dig @1.1.1.1 _acme-challenge.example.com soa

; <<>> DiG 9.16.1-Ubuntu <<>> @1.1.1.1 _acme-challenge.example.com soa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6781
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_acme-challenge.example.com. IN SOA

;; ANSWER SECTION:
_acme-challenge.example.com. 60 IN CNAME 93b0b213-4946-4007-aa76-685ce2f5f760.auth.example.com.

;; AUTHORITY SECTION:
auth.example.com.	3600	IN	SOA	auth.example.com. noc.example.com. 2023083109 28800 7200 604800 86400

;; Query time: 48 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Aug 31 13:08:01 CEST 2023
;; MSG SIZE  rcvd: 168

I think the issue is that the pdns-recursor is not returning the SOA record, but this is just a wild guess. I don't really understand why the responses are so different, because the pds-recursor is configured to forward all queries to 1.1.1.1/ 8.8.8.8 anyway:

forward-zones-recurse=.=[2606:4700:4700::1111];1.1.1.1;[2001:4860:4860::8888];8.8.8.8

[phonedph1]

The @pdns-recursor dig query looks more like it's talking to an auth server and not a recursor instance.

Are you sure something isn't listening on that IP/port instead?

[omoerbeek]

The reason that @phonedph1 thinks the query is ran against an authoritative server is the

;; WARNING: recursion requested but not available

which is printed by dig if the ra flag was not set on the reply, which indicates an authoritative server replying.

Please show us your complete configuration.

This looks more like a support question, so I'm turning this to a discussion.

[sndrsmnk]

In the dig @pdns-recursor example the flags also indicate authoritative answer (aa flag):

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

So it seems you're not talking to a recursor there.

[gucki]

Hello @phonedph1 and @omoerbeek, thank you for your really quick replies. You are completely right, things got mixed up during my analysis and the reply above is not from the pdns-recursor. Indeed the responses now look as expected. I finally was also able to get it working by adding max-negative-ttl=1 to my recursor config. Sorry, for the confusion, guess I need a break now...