@schoen Thanks! I did not know it any of this info was sensitive so i just redacted everything.
@cpu Thanks for the help. If I correctly understand what you wrote the bug only made the error pop out different and had nothing to do with the CAA lookup failure itself. Do you have any pointers on that? The hostingprovider for that domain does not yet support CAA records, could that be the problem? or do I need to look elsewhere? Any help would be much appreciated.
Hi @joeyboon - that's correct.
Sure! We have a documentation page on CAA that is probably the best resource. In your case your DNS provider is falling into the "SERVFAIL" bucket described on that docs page. They don't need to support adding CAA records but they do need to respond the correct way when Let's Encrypt asks if you have a CAA record. You could contact your DNS provider to ask about why they return the incorrect SERVFAIL status or you could switch to an alternative DNS provider.
Hope that helps!
I solved it! Problem was located at my domain registrar. They had to reset DNSsec for the domain. Now everything works like a charm! Thanks again for helping out a noobie 
Looks like recent changes broke this again. The libreswan.* domains, which are DNAMEs to libreswan.org all broke 
we changed all libreswan.* domains to not use DNAME for now, and left libreswan.net broken so it can be used to diagnose and test. We do want to go back to using DNAMEs again for all domains through…
Hi @letoams,
In the process of working through the legacy CAA implementation we were required to deploy to meet the baseline requirements we made a choice to not support DNAMEs.
I believe this will work when we return to an erratum 5065 CAA tree climbing algorithm. We're petitioning various parties/root programs to try and get back to this state ASAP.