payments.wikimedia.org is only a single hostname cert though right? I haven't looked into the details of CAA but hopefully it would be possible to set up such an exception just for that record alone, without having to whitelist it for the whole of wikimedia.org?
Looks like corp uses DigiCert.

I don't think gdnsd supports CAA records yet

I checked and indeed it doesn't. I filed this in gdnsd's bug tracker as bug #138.

As mentioned in the description, this is not strictly a blocker: we can still use the RFC 3597 syntax for unknown RR types, which gdnsd does support too.

Change 356200 had a related patch set uploaded (by Faidon Liambotis; owner: Faidon Liambotis):
[operations/dns@master] Add CAA records for wikimedia.org/wikipedia.org

https://gerrit.wikimedia.org/r/356200

• Domains:

Why start with just wikipedia and wikimedia? We could go after our lower-traffic domains first as a test, but since we don't issue individual certs for them there's no real functional testing to happen there. Perhaps we could use a lesser domain just to validate that other tools parse and validate the CAA correctly from the public DNS view, though. Once we turn on the big two, we may as well turn on all the others as well (even the non-canonicals, IMHO).

• GlobalSign:

Since GlobalSign isn't yet checking CAA, technically we can put in nothing for them and our issuances from them would be unaffected. There's some possible minor fallout in that some auditing tools might flag this (when they see that we have a valid cert from GS but do not authorize GS), but they should allow for it to still be considered a legitimate situation according to the RFC.

The way I'm reading the spec, there is no "registry" so to speak of official domainnames that CAs are using to validate with. We can guess that they're likely to check against "globalsign.com". However, they could decide tomorrow to start validating CAA and using "globalsign.net" instead for whatever reason, and we have no way to predict that. In either case the meaning of the value is clear, though: if we add globalsign.com as an issuer, it's not an arbitrary label, it does refer to the owners of the globalsign.com domainname in the DNS. Another CA can't legally (by CA/B rules) validate against that unless they purchase that domainname from GlobalSign first (or somehow otherwise become explicitly authorized by GlobalSign).

Regardless, whether we include it or not, we'll need to keep tabs on globalsign's CAA progress and possibly make changes when they start supporting CAA. I tend to favor pre-emptively including it now because it sends a more correct and consistent signal to anyone who's auditing us from a public perspective.

In T155806#3300964, @BBlack wrote:

(even the non-canonicals, IMHO).

Possible with the empty issuer for now, since we don't have plans to issue certs for them at all until we've set up a service for it...

I'm not 100% sure if it was obvious from my description above, so forgive me if I'm repeating something you know already: CAA records are meant to be used only at the moment of issuance and only by CAs, not after the fact and not during the lifetime of the certificate.

As such, noone should be really auditing our existing certificate vendors against our CAA records -- they're not guaranteed to be in sync (and in fact may not be when we're switching vendors but keeping existing certificates lives etc.). That also means that the worst thing that can happen if we don't monitor GlobalSign's rollout of CAA is that (at most) we won't be able to issue a certificate in under $TTL, which is set at 5 minutes in the proposed patch set, so it's not a big deal. The same applies to testing this in smaller domains and messing this up; the iodef mailto will help with us catching those issues as well.

Happy to add globalsign.com to the set though, up to you and no objections in rolling this out to all domains as well. Should I amend the patchset for that?

We talked a bit on IRC. Probably the first step is to include all the canonical domains (the 14-domain set in our big unified cert):

wikipedia.org
wikimedia.org
wiktionary.org
wikiquote.org
wikibooks.org
wikisource.org
wikinews.org
wikiversity.org
wikidata.org
wikivoyage.org
wikimediafoundation.org
mediawiki.org
wmfusercontent.org
w.wiki

... and set all of these for digicert+globalsign, except for wikimedia.org which also needs LE (as in the current ticket).

Because some of these are symlink targets for non-canonical domains in our DNS repo, it will apply the CAA record to them as well. I think we can live with that for now (it doesn't hurt anything), and look to do some followup work afterwards on cleaning up the non-canonical and/or "parking" cases (probably setting them to no-issuers-allowed initially, until we start working seriously on T133548).

Change 356200 merged by BBlack:
[operations/dns@master] Add CAA records for wikimedia.org/wikipedia.org

https://gerrit.wikimedia.org/r/356200

ssllabs confirms the expected changes above. The sslmate generator doesn't allow for custom entries to get globalsign.com in early (as a likely guess for when they flip their switch before the impending CA/B deadline).

Change 362419 had a related patch set uploaded (by BBlack; owner: BBlack):
[operations/dns@master] CAA: add records to all canonicals

https://gerrit.wikimedia.org/r/362419

Change 362419 merged by BBlack:
[operations/dns@master] CAA: add records to all canonicals

https://gerrit.wikimedia.org/r/362419

Change 369575 had a related patch set uploaded (by BBlack; owner: BBlack):
[operations/dns@master] add "issue globalsign.com" to CAA recs

https://gerrit.wikimedia.org/r/369575

Change 369575 merged by BBlack:
[operations/dns@master] add "issue globalsign.com" to CAA recs

https://gerrit.wikimedia.org/r/369575