lexicon icon indicating copy to clipboard operation
lexicon copied to clipboard
verified publisher icon AnalogJ

Support CAA records

Open kapouer opened this issue 7 years ago • 23 comments

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/

kapouer avatar Aug 30 '18 21:08 kapouer

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 :)

AnalogJ avatar Sep 14 '18 07:09 AnalogJ

That's fair, i think it's too early to expect that level of coverage.

kapouer avatar Sep 14 '18 07:09 kapouer

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.

  • [x] AWS Route53
  • [x] ClouDNS
  • [x] Constellix
  • [x] DigitalOcean
  • [x] DNSimple
  • [x] EasyDNS
  • [x] ExoScale
  • [x] Gandi (old API)
  • [x] Gandi LiveDNS API
  • [x] GoDaddy
  • [x] Google Cloud DNS
  • [x] Linode
  • [x] Linode v4
  • [x] LuaDNS
  • [x] OVH
  • [x] PowerDNS
  • [x] Rage4
  • [x] Subreg
  • [x] Vultr
  • [x] Zeit
  • [x] Zonomi
  • [ ] Gehirn.jp
  • [ ] Glesys
  • [ ] AuroraDNS
  • [ ] Cloudflare
  • [ ] CloudXNS
  • [ ] DnsMadeEasy
  • [ ] DNSPark
  • [ ] DNSPod
  • [ ] Memset
  • [ ] Namecheap
  • [ ] Namesilo
  • [ ] NS1
  • [ ] OnApp
  • [ ] Online.net
  • [ ] PointHQ
  • [ ] Rackspace
  • [ ] Sakura Cloud by SAKURA Internet Inc.
  • [ ] SoftLayer
  • [ ] Transip
  • [ ] Yandex

alainwolf avatar Sep 14 '18 17:09 alainwolf

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 avatar Sep 20 '18 15:09 AnalogJ

@AnalogJ What exactly are the tasks needed to implement support for "CAA" records other than adding "CAA" to the sub-parsers of providers?

rqelibari avatar Oct 27 '18 13:10 rqelibari

@rqelibari i'd say updating the tests for each provider ?

kapouer avatar Oct 30 '18 18:10 kapouer

@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?

rqelibari avatar Oct 30 '18 22:10 rqelibari

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 ?

kapouer avatar Oct 30 '18 23:10 kapouer

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.

rqelibari avatar Oct 31 '18 11:10 rqelibari

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 avatar Oct 31 '18 16:10 AnalogJ

@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!

rqelibari avatar Nov 07 '18 13:11 rqelibari

Well, all providers I developed seem to support CAA. I will definitively have a look on it.

adferrand avatar Nov 07 '18 14:11 adferrand

Unfortunately online does not support CAA yet (though they added support for TLSA recently which is a good sign).

kapouer avatar Nov 07 '18 14:11 kapouer

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.

kapouer avatar Jan 19 '19 23:01 kapouer

in any case i think lexicon should be agnostic - so the purely technical issue is still open.

kapouer avatar Jan 19 '19 23:01 kapouer

Just a small note, Namecheap now supports CAA records.

krusic22 avatar Feb 14 '19 17:02 krusic22

unsurprisingly the "online" provider provides CAA records as well

kapouer avatar Feb 14 '19 17:02 kapouer

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 avatar Feb 15 '19 09:02 rqelibari

@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.

kapouer avatar Feb 15 '19 09:02 kapouer

@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

kapouer avatar Feb 19 '19 14:02 kapouer

Odd how this seems stalled. I would have assumed that many more DNS providers support CAA records now. Is anyone working on this currently?

eengstrom avatar May 08 '20 13:05 eengstrom

It's trivial to implement, someone motivated could PR this in a day of work (lexicon's test framework is well documented).

kapouer avatar May 08 '20 16:05 kapouer

I will work on this issue, this week. When I succeed, I will create a PR.

schiederme avatar Jul 20 '20 19:07 schiederme