Thanks everyone for the useful feedback and filling in the gaps for me.
We’ve now gone full circle since the easiest solution is to destroy and
re-create a few VMs and a Raspberry Pi with the latest and greatest release and
pkgsrc/apt (Viktor - I checked and latest Raspbian gets me Unbound
Viktor Dukhovni writes:
> Yes, the expected behaviour when you explicitly request a CNAME
> record is that (modulo DNAMEs in some parent zone) the qname is
> resolved without further indirection, returning a CNAME if present
> there, NXDOMAIN if the qname does not exist, or else NODATA.
Spot on.
[posting in a personal capacity]
> Let's Encrypt is in general very happy to follow indirections
I believe the CNAME processing being discussed in this thread is
standard practice for CAs beyond Let's Encrypt / ACME / RFC 8555 that
perform domain validation through the "DNS change" mechanism
Rob Seastrom wrote:
>
> I might add that I was slightly surprised that this works - it seems
> unaddressed in the ACME spec but kind of feels like a potential attack
> surface tparticularly since it works even to a non-child,
> non-same-origin (pedantically, not quite "out of baliwick" but YKWIM)
On Wed, Oct 09, 2019 at 12:10:43AM -0400, Viktor Dukhovni wrote:
> What version of unbound is this?
I failed to note the bottom of your message. Unbound 1.6 is rather
old now. The current version is at least 1.9.3. Also, a parent
domain of the target:
_acme-challenge.funnel.seastrom.com.
> On Oct 8, 2019, at 10:06 PM, Rob Seastrom wrote:
>
> The expected behavior is that I would get back the CNAME record and NOERROR
> when asking for a CNAME even if it points somewhere that has no data. Indeed
> this is what I get from a recent version of BIND, Power, Google DNS, and
>
Dear Colleagues,
As part of refining an Ansible role for handling ACME dns-01 handshakes with
LetsEncrypt, I ran into some odd intermittent failures which at first I
hypothesized might be a bug in dnspython, which is the back-end for Ansible's
lookup('dns' ...) call.
They turned out to be
