unbound replaces CNAME query with A query?

[Christoph]

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.

> _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.

> What is the point of querying just CNAME? Does it have a specific
> reason?

> Unbound seems proactive to fetch actually useful record instead of
> just intermediate CNAME I am not sure that has to be strictly wrong.
> The result it delivers is similar. It tells there is CNAME and its
> target does not exist. 

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.

> It just seem the stub does not check actual
> contents of message except rcode. Can stub resolver do anything
> useful with information that there is CNAME not leading to final
> destination?


> 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