Open kapouer opened 5 years ago
Hey @kapouer
This is very similar to #286, so I'm just going to copy my comment from there:
lexicon's primary purpose to interact with providers in a standardized way. Theoretically thats a good thing but it does mean that occasionally we're limited to the features of the lowest common denominator.
I'm not familiar with the CAA record type, but I'd be happy to add it if you would be willing to do a bit of research and tell me which lexicon providers currently support it. I'm looking for at-least 70% support before I add it to the list of supported record types.
Hopefully that makes sense :)
That's fair, i think it's too early to expect that level of coverage.
From the 41 providers listed in the lexicon README.md ... 21 providers (51%) support CAA records. That is less then 70%.
But if you look at their names, the big ones clearly tend to support it. Cloudflare doesn't support it yet by API, but they will soon, as they are among the strongest supporters. This leaves me with the impression, that still over 70% of the users would benefit from it. But who knows.
Hey @alainwolf Thanks again for researching this.
Yeah, I agree. It looks like there's enough support for CAA records across the large providers to make this a meaningful change. If either of you want to open a PR, I'd be happy to merge it.
@AnalogJ What exactly are the tasks needed to implement support for "CAA" records other than adding "CAA" to the sub-parsers of providers?
@rqelibari i'd say updating the tests for each provider ?
@kapouer Do you have some special test case in mind? As lexicon is not using a TDD approach I think the current test sets are totally sufficient as all providers that pass the TXT record tests already prove to be able to add DNS records. New tests would not add any more confidence in the code. What do you think? Am I missing something?
Well i don't know the exact purpose of the tests, but i'm sure some providers don't support CAA records. Is lexicon supposed to test that fact ?
The question is: Do you (or anyone for that matter, especially @AnalogJ) think there might be DNS services that require other steps to add a CAA record than to add a TXT record?
In my opinion further tests are necessary if and only if the answer to that question is yes.
Hey @kapouer @rqelibari @alainwolf
Yeah, @rqelibari hit the question on the nose. If CAA
records can be treated like TXT
/A
/CNAME
/etc records where name
and content
are the primary requirements, then adding support for CAA
would be as simple as inserting it into the list here: https://github.com/AnalogJ/lexicon/blob/master/lexicon/__main__.py#L27
I'm not quite convinced that adding a CAA
record requires its own extended test suite yet, but if we do find that content
and name
fields are not enough, then yeah, an extended/optional test suite will be required as well.
Would one of you be willing to modify lexicon and try creating CAA
records with supported providers that you have credentials for?
@AnalogJ I will look into it (this weekend maybe, but cannot promise). I will modify lexicon
and the easyname provider.
To anybody who has enough time and wants to help: feel free to join!
Well, all providers I developed seem to support CAA. I will definitively have a look on it.
Unfortunately online
does not support CAA yet (though they added support for TLSA recently which is a good sign).
Hi there ! I recently found out that CAA records are really not a good thing for open-source and free software. Please have a look at this: https://dev.to/kapouer/caa-records-only-have-a-meaning-in-a-world-without-free-ssl-providers-34cb for explanations. I won't support CAA records anymore.
in any case i think lexicon should be agnostic - so the purely technical issue is still open.
Just a small note, Namecheap now supports CAA records.
unsurprisingly the "online" provider provides CAA records as well
in any case i think lexicon should be agnostic - so the purely technical issue is still open.
I totally agree. But a word on your linked article:
Hi there ! I recently found out that CAA records are really not a good thing for open-source and free software. I won't support CAA records anymore.
In my opinion CAA
is not dangerous to open source, as nothing is kept secret here and the RFC itself is actually open source. If you mean a danger to free SSL certificates, I disagree again. If I have read the RFC correctly, everyone is free to name Let's Encrypt in their respective CAA
record and nobody would have to pay a dime.
At the same time the CAA
record actually adds valuable information to the certificate validation process of the web browser or any other client software. If a domain specifies a CAA
record, anybody will know, which issuer can be trusted to have actually issued a certificate for a specific domain. If a certificate authority not named in a CAA
record, gets compromised, the domain administrator would not have to care at all, because he'd already have told people, that they should not trust certificates issued by that compromised certificate authority.
See also SSL Pinning which is a similar concept.
@rqelibari yeah i was really disturbed by some stupid policy of a contractor who did not allow letsencrypt certificates - i'm sorry i shouldn't have ranted around here.
@AnalogJ btw CAA records are manipulated like TXT record, nothing fancy that i know of. There is a nice list of supported providers here: https://sslmate.com/caa/support
Odd how this seems stalled. I would have assumed that many more DNS providers support CAA records now. Is anyone working on this currently?
It's trivial to implement, someone motivated could PR this in a day of work (lexicon's test framework is well documented).
I will work on this issue, this week. When I succeed, I will create a PR.
this allows one to use a DNS record to restrict which CA are allowed for a given domain.
https://tools.ietf.org/html/rfc6844 https://sslmate.com/caa/