Open Faeranne opened 5 years ago
Did you start with a fresh 18.04, or did you upgrade from 14.04? Your striked through text says the server is still issuing incorrect DANE TLSA, was it working in 14.04? I feel like mine is working; what is a good way to test this? (the online TLSA validators say things are fine for my domain)
Fresh install. It worked fine in 14.04. I haven't tried re-adding the CAA records to see if the issue comes back, but I will this evening..
Re-adding didn't result in any new issues, so it appears to only affect restores from 0.3 to 0.4
Not sure if there is some confusion going on, I tested my domain at https://www.ssllabs.com/ssltest and it did not find a CAA record. Above you show dig output for DANE. Are you entering your own CAA record? I'm not sure that MIAB is auto generating one.
Ya, sorry, the dig output was for the original issue. Apparently you can't strike through blocks of text (or at least I haven't figured out how), so there is a bit of confusion there. The CAA record is manually added via the custom dns page.
I just added a CAA record without error.
I went to custom dns and added type CAA and filled this in the field: 0 issue "letsencrypt.org"
save was fine, tools/dns_update was fine, management/dns_update.py reports entry as fine and the check at https://caatest.co.uk/ report things are good.
We'll see in a month if my certs renew properly.
The bug only seems to affect imported boxes from v3.0 backups. Adding new records seems to work just fine.
I have managed to replicate the error when importing. Turns out if the issuer address isn't quoted, it works fine until you add a second CAA entry to the same domain. I've included both working and broken examples of the dns/custom.yaml file:
Works in both 3.0 and 4.0:
projectmakeit.com:
CAA:
- 0 issue "letsencrypt.org"
- 0 iodef "mailto:admin@projectmakeit.com"
Works in 3.0 but not in 4.0
projectmakeit.com:
CAA:
- 0 issue letsencrypt.org
- 0 iodef "mailto:admin@projectmakeit.com"
Looks like it stems from
ldns-signzone
breaking when trying to parse CAA records. The solution right now is to correct the records in/etc/nsd/zones/
and runldns-signzone
manually, then deleting the records from the Custom DNS interface, and finally, runningdns_update
manually. correcting the zone entries has to be done first, as the dns api errors out until that is fixed, and won't allow you to remove existing records.Error when running
ldns-signzone
:Zone not read, error: Syntax error, could not parse the RR's rdata at /etc/nsd/zones/projectmakeit.com.txt line 16
which readIN CAA 0 iodef "mailto:admin@projectmakeit.com"
~After following the update procedures to move from v0.30 to v0.40 and from ubuntu 14.04 to 18.04 on DigitalOcean, everything has gone smoothly, except the dns server is still issuing an incorrect DANE TLSA record. I've checked the dns directly using
dig @ns1.box.projectmakeit.com ANY _25._tcp.box.projectmakeit.com
and still see the old entry. The current message on the status page isThe DANE TLSA record for incoming mail (_25._tcp.box.projectmakeit.com) is not correct. It is '3 1 1 7b421ccedc12fcfb1706813555867dc400d29ccdc95f56cb2a321daef03d5126' but it should be '3 1 1 de108a11b619aa4ecef4e6dc264de4dcbc80d636a64ac32d0af31b744253799d'. It may take several hours for public DNS to update after a change.
~~Since these are automatically generated, I can't see how to force it to be updated.~
~dig output:~