unbound replaces CNAME query with A query?
pemensik at redhat.com
Fri Mar 31 11:35:00 UTC 2023
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
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
;; 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
> 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
> 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
> 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
>> 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.
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.
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
More information about the Unbound-users