Yes, subdomains work check https://dane.3b. The same certificate is used for 3b and dane.3b you can add a TLSA record for the subdomain pinheadmz.proofofconcept. I didn't find one when looking for _443._tcp.pinheadmz.proofofconcept

The names in the certificate are ignored and are not used for authentication at least when it comes to DANE-EE(3). See RFC7671 Section 5.1

Authentication via certificate usage DANE-EE(3) TLSA records involves
simply checking that the server's leaf certificate matches the TLSA
record. In particular, the binding of the server public key to its
name is based entirely on the TLSA record association. The server
MUST be considered authenticated even if none of the names in the
certificate match the client's reference identity for the server.

IIRC, you can use a single certificate for all your subdomains and even entirely different domains as long as they have a TLSA record matching the provided certificate. The expiration date of the certificate is ignored as well.

Got it ok thanks - so I'm trying to wildcard all subdomains to use the same TLSA without defining each subdomain as its own record. I've tried two methods:

Wildcard -> CNAME

The cname links all subdomains to the root, which has a TLSA record at _443._tcp...

I guess this doesn't work because of how the prefix pseudo-subdomains are added but I was hoping the recursive resolver would see the CNAME and continue its lookup using _443._tcp.<root> but I guess the CNAME only really works for record types, not prefixes.

* IN CNAME <root>
_443._tcp.<root> IN TLSA <...>

Wildcard -> TLSA

* IN A <same IP as root>
* IN TLSA <...>

This actually does return a TLSA record for any matching request including _443._tcp.SUBDOMAIN.<root> but the signature is over a wildcard, so I wonder if that is why it is still not validating.

Is there a way to get more logging output from godane?

Do you have any ideas how to apply TLSA records to a wildcard in this way such that any subdomains are also secured by DANE?

The second approach should work fine. I added the following records for *.dane.3b

*.dane.3b. IN A <IP>
*.dane.3b. IN TLSA <....>

you can try ANY-SUBDOMAIN.dane.3b and it should work.

I checked subdomains at *.proofofconcept with dig. It seems there is no "ad" flag returned so that's the issue.

Is your name server signing wildcard matches on the fly? I notice when I dig <random>.proofofconcept I always get back the same RRSIG (over the '*' record) and I read that validating this requires an NSEC, which I'm not sending, so I need to look into that. But your name server returns different RRSIGs for every random prefix, which my server is also not doing yet.

I compared our setups using delv:

;; validating xyz.dane.3b/A: in fetch_callback_dnskey
;; validating xyz.dane.3b/A: keyset with trust secure
;; validating xyz.dane.3b/A: resuming validate
;; validating xyz.dane.3b/A: verify rdataset (keyid=64038): success
;; validating xyz.dane.3b/A: marking as secure, noqname proof not needed

vs.

;; validating x.proofofconcept/A: in fetch_callback_dnskey
;; validating x.proofofconcept/A: keyset with trust secure
;; validating x.proofofconcept/A: resuming validate
;; validating x.proofofconcept/A: verify rdataset (keyid=58608): from wildcard
;; validating x.proofofconcept/A: looking for noqname proof
;; validating x.proofofconcept/A: noqname proof not found
;; no valid NSEC resolving 'x.proofofconcept/A/IN': 127.0.0.1#5350
;; resolution failed: no valid NSEC

OK, I got this working with sign-on-the-fly software. Thanks for your help @buffrr and for this cool tool!