unbound replaces CNAME query with A query?

[Petr Menšík]

I have tried to reproduce it on my own unbound-1.17.1-1.fc36.x86_64, but 
it does not behave like you have described after flushing the cache. Not 
to me. I just guess there might be something else required, but not sure 
what. Is there something in unbound logs, which would make hint why it 
forwarded A query instead? Can you try increasing verbosity by 
unbound-control verbosity <newvalue> and query the name afterwards?

$ unbound-control flush_zone . && dig 
_acme-challenge.bender-doh.applied-privacy.net CNAME
ok removed 310 rrsets, 218 messages and 16 key entries

; <<>> DiG 9.18.13 <<>> _acme-challenge.bender-doh.applied-privacy.net CNAME
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23092
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_acme-challenge.bender-doh.applied-privacy.net.    IN CNAME

;; ANSWER SECTION:
_acme-challenge.bender-doh.applied-privacy.net.    86400 IN CNAME 
bender-doh.acme-dns-challenge.applied-privacy.net.

;; Query time: 177 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Fri Mar 31 13:06:33 CEST 2023
;; MSG SIZE  rcvd: 119

On 3/30/23 23:28, Christoph wrote:
> Hi Petr,
>
> thanks for your reply and your questions.
>
> Petr Menšík via Unbound-users:
>> Correct me if I understand it not correctly. whether you query CNAME
>> or A record should not make a difference in NXDOMAIN status. But in
>> any case the answer is not there. How does it change ACME process
>> when there is NXDOMAIN and not just no-answer NOERROR response?
>
> That CNAME DNS query is used by lego - an ACME client - to find
> the DNS record it has to update (the ACME DNS TXT challenge).
> Lego's CNAME support used to be experimental and is now enabled by 
> default.
>
> The NXDOMAIN answer results in lego concluding "there is no CNAME".
> The impact of that unexpected NXDOMAIN answer is that lego will attempt
> to use the provided DNS API key to create a TXT record it has no
> permissions for. It only has permissions for the target of the existing
> CNAME.
> For this reason the NOERROR and its answer is important, even if the
> final record in that CNAME chain does not exist. It is lego's job to
> create it.

Okay, I would have expected TXT query before the update, but okay. The 
problem is I see different behaviour on the same version as you have. So 
the primary reason you are quering this name is to prepare UPDATE query. 
But you want to update only CNAME target if there is any, not the 
original name itself.

Anyway, the answer contains CNAME in ANSWER section, even if the status 
is NXDOMAIN. So even with this unusual reply the software should be able 
to decipher where the queried name leads to. The only part wrong in the 
answer is NXDOMAIN status. I admit it usually arrives with empty answer. 
Not sure the answer with CNAME present is against RFCs.

>
>> _acme-challenge.bender-doh.applied-privacy.net exists with cname. Its
>>  cname target returns NXDOMAIN. So yes, it is a bit confusing what is
>> the final result. What exactly is the stub in this case? libresolv
>> library?
>
> It is running lego on a FreeBSD server.
>
> I hope the text also helps with answering your other questions below, if
> it is not clear please let me know and I will try to rephrase.
>
> If unbound is just trying to be useful then it should still be 
> consistent and provide the same answer if you ask it twice - which is 
> not the case currently.

I am running it on Fedora 36. I doubt it should have different results.

Yes, I agree it should return the same answer. It could differ only in 
minor differences like used opt parameters. But not different status. If 
you ask the first or the third time, result should differ only in TTL or 
something insignificant.
>> Note: it would be much easier if you could share just pcap containing
>>  the problem instead of only text description.
>
> I actually was hoping to achieve the opposite, because looking at the
> text does not require people to have a pcap parser and open a file 
> from a mailing list but you got the gist of it anyway.
>
> thanks,
> Christoph
>
Okay, it might be just my preference. The thing is those packet 
descriptions are not compact, it makes the message quite long. dig-like 
output would be better, but that is more difficult to get from pcap file.

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB