[Pdns-users] Rcode 3 NXDOMAIN for existing CNAME

[Christoph]

Hi,

let me start with some context information:

We are using the lego [1] ACME client
with a DNS challenge and desec.io as our DNS provider
and run into a problem that results in the failure of certificate renewals.

According to the lego developer the root cause is a DNS issue [2] in our 
environment.

We captured and inspected lego's DNS traffic when renewals fail,
to see whether we can confirm DNS as the root cause.
While looking at the DNS packet we noticed that the DNS server returns:
RCode: 3
even when it contains the relevant record in the answers.

Wireshark copy paste:
domain shortened to simplify

Domain Name System (response)
      Transaction ID: 0x18c6
      Flags: 0x8403 Standard query response, No such name
          1... .... .... .... = Response: Message is a response
	[...]
          .... .... .... 0011 = Reply code: No such name (3)
      Questions: 1
      Answer RRs: 2
      Authority RRs: 6
      Additional RRs: 1
      Queries
          _acmE-cHAllenge.doh.applIEd-PRIvAcy.NeT: type A, class IN
      Answers
          _acmE-cHAllenge.doh.applIEd-PRIvAcy.NeT: type CNAME, class IN, 
cname doh.acme.applIEd-PRIvAcy.NeT
          _acmE-cHAllenge.doh.applIEd-PRIvAcy.NeT: type RRSIG, class IN
      Authoritative nameservers
      Additional records


We reached out to DeSEC and they confirmed and reproduced it
and provided an description of why this happens: PowerDNS Authoritative 
follows CNAMEs when they are on the same server. If the final lookup 
does not exist it returns NXDOMAIN to the first query
even when the qname from the first query does exist.

Example:

desired certificate is for: doh.applied-privacy.net

_acme-challenge.doh.applied-privacy.net CNAME
-> doh.acme.applied-privacy.net

The reason for the CNAME: lego gets an API key that
is authorized to write to the domain acme.applied-privacy.net only (not 
to applied-privacy.net) to reduce the impact on API key compromise.

lego has CNAME support for this setup and follows CNAMEs
before creating the TXT record, but since the first lookup returns 
NXDOMAIN already it attempts to use the API key for a zone it has no 
access to. It is not expected to get an NXDOMAIN Rcode for an existing 
CNAME record.

Does this behavior meet RFC standards? (so lego is wrong?)
Can the behavior be changed by a configuration setting?

thanks!
Christoph

[1] https://go-acme.github.io/lego/
[2] https://github.com/go-acme/lego/issues/1739