@jsha actually it does matter because of how many cloud/enterprise hosts handle DNS record updates. Assume this validation is wanted:
example.com*.example.com
Most clients (including certbot) will generate/present the auth challenges in serial – so an automatic system will set the first record, then the second.
Many cloud systems appear to have an internal cache that lasts from 60s to 300s (possibly tied to their minimum TTL, possibly not; possibly primed via a write-through-cache, possibly not; also possibly affected by internal caching systems propagating outwards). Setting a second value on these systems for the same key in a TXT record doesn't appear to write into the cache.
So in this flow:
- Generate challenge for
example.com - Set challenge for
example.com; - Generate challenge for
*.example.com - Set challenge for
*.example.com; - Validate the challenges
With at least 3 consumer DNS systems, Step 2 will cause that TXT record to somehow cache and delay Step 4 from being readable until it somehow expires.
The "fix"* it to patch Certbot and have the client sleep between steps 4&5 for a minimum time that accounts for:
- The record set in Step 2 to expire
- The record set in Step 4 to propagate
One vendor I tested against seemed to handle this in 90s for a 60s TTL; two other vendors with a 300s TTL couldn't handle this repeatably without a 360s TTL.
Using the default hooks (unpatched), one would need to sleep 90 or 360s after every record is set -- that translates to 12 minutes for a single domain+wildcard combo, and over 3hours for the max of 50 on a cert.
Allowing a *.example.com and example.com to use the same challenge when combined ina single CSR would make this process much faster - and therefore easier to test and deploy.
* I'm calling the above a "fix" in quotes, because the right solution is migrating to ACME-DNS. That is not an option for everyone though. (Thankfully it was for me, because I have nearly 50 domains and 12 of them are on a single cert)