Closed Bug 882128 Opened 11 years ago Closed 4 years ago

Support CAA records on mozilla.org domain

Categories

(Infrastructure & Operations :: DNS and Domain Registration, task)

Product:
Infrastructure & Operations
Component:
DNS and Domain Registration
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: gerv, Unassigned)

References

(
URL
)

Details

(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/19/6903]) 

CAA is a way of specifying, in the DNS, the names of the CAs who you want to be able to issue certificates for your domain. CAs will, in the future, be checking this record and flagging up requests which are inconsistent with it as "high risk". The aim here is to prevent misissuance, which is something Mozilla is keen to avoid. (Note previous misissuances for e.g. addons.mozilla.org by ComodoHacker.)

The RFC is: http://tools.ietf.org/html/rfc6844

We should gather together a list of the CAs we use across mozilla.org, work out the correct CAA record and insert it into our DNS. We also need to put in place a procedure or note that this record should be updated in the case that we decide to start using a new CA.

I am happy to read the spec and work out the correct format of the record, if someone from IT can give me a list of the CAs we use.

Gerv
Punting over to webops to get a list of the CA's we use across our various web properties

:gerv

Could you provide some input on what data we'll need to obtain exactly? Is a list of the CA names sufficient? The RFC was published in September of 2011 so I think it's still fairly new, and beyond the RFC the available documentation is a little sparse.
Assignee: server-ops-infra → server-ops-webops
Component: Server Operations: Infrastructure → Server Operations: Web Operations
QA Contact: jdow → nmaul
Setting need info? for #c1.
Flags: needinfo?(gerv)
Getting a complete list will be a rather large undertaking... we have many domains or subdomains that are hosted by 3rd parties, which we don't manage the CA's for. This includes things like CDNs (most of which are <something>.cdn.mozilla.net), which we have a little control over, but also things like sendto.mozilla.org, for which we have almost no control over- that cert could change at any time and we wouldn't know unless they told us.

We manage a whole lot of domains. It might be most feasible to tackle this somewhat like we handled DNSSEC and Akamai-DNS migrations. Namely, add the relevant records for sets of domains at a time, for which we can more easily verify each one beforehand and have confidence in the change.

The hardest domain will be the one we're probably most interested in, of course... mozilla.org.

This will almost certainly have to wait until Q3 for any significant amount of work to begin. We don't really have the cycles to spend on this in Q2.
digi: The CAA record takes the domain name of the CA - that's all we need. (I believe it can be any domain the CA owns, but we should use their main one.)

jakem: I agree that incremental is the way to go. And we should start with the domains for which a misissuance would be most dangerous. 

CAA can be scoped to any part of the domain tree. So, I suggest we start with a CAA record for addons.mozilla.org, which is a single website which is a high value target and (presumably) only uses a single CA. (As far as I can tell, Verisign.)

Then, we should add an issuewild CAA record to the mozilla.org domain, which prevents anyone except the listed CAs issuing a wildcard cert for *.mozilla.org. If we use such wildcard certs, I'm pretty sure we will only obtain them from one or two CAs. This protects AMO from being attacked via the wildcard route, without preventing those controlling e.g. sendto.mozilla.org from getting a specific cert for their server.

Those two things would provide good protection for AMO.

Once we've done that, we could consider what other high value targets there are, and produce CAA records for each of them individually. It could be that an "issue" record for mozilla.org (which would control issuance for any domain in mozilla.org) is out of our reach in the short term, but that's OK.

If our CDN is all at mozilla.net rather than mozilla.org, that's fine, because that's a separate domain so we don't have to worry about it at all if we don't want to.

Remember that CAA doesn't block issuance entirely; the plan is to make the CA sit up, take note and check very carefully that it's not about to misissue. So we don't need to worry that things will get totally bricked if we get this wrong in some way.

Gerv
Flags: needinfo?(gerv)
So here are the questions we need answers to:

* Do we use a *.mozilla.org cert at all? If so, who issues it for us?

* Does addons.mozilla.org use a single certificate, as appears to be the case? Is Verisign 
  the provider?

digi: I'm in Mountain View tomorrow and Friday if it would help to sit down and talk about this.

If we can get answers to those two questions, we can produce an issuewild record for mozilla.org and an issue record for addons.mozilla.org, and thereby protect addons from misissuance from CAs who are checking CAA.

Gerv
jakem says: we have two providers of wildcard certs - usually GeoTrust, occasionally DigiCert. 

In terms of addons.mozilla.org, Verisign do the main EV cert, but there's also https://forums.addons.mozilla.org/, which is simply a redirect, but it uses a GeoTrust cert.

oremj: jakem says you are the primary ops guy for addons; do you have anything to add?

For posterity, you can view the CAA records for a domain in human-readable form as follows:
dig +short -t TYPE257 google.com | perl -nE '@x = split(); say map(chr, map { hex } ($x[2] =~ m/../g ))'
(slightly hacky)

Gerv
Digicert say that "digicert.com" is the correct value to use for them. For geotrust, I will check but I assume "geotrust.com". For AMO, as Verisign and GeoTrust are both Symantec brands, we can do what Google does and use symantec.com. 

Gerv
Note to self: digi is the man to make the DNS changes once we've worked out what they are.

Gerv
(In reply to Gervase Markham [:gerv] from comment #5)
> If we can get answers to those two questions, we can produce an issuewild
> record for mozilla.org and an issue record for addons.mozilla.org, and
> thereby protect addons from misissuance from CAs who are checking CAA.

:gerv, to confirm, we're still waiting on answers for these two questions per comment 6 and comment 7?

(In reply to Gervase Markham [:gerv] from comment #6)
> oremj: jakem says you are the primary ops guy for addons; do you have
> anything to add?

Setting needinfo? :oremj for this.

(In reply to Gervase Markham [:gerv] from comment #7)
> For geotrust, I will check but I assume "geotrust.com".

Setting needinfo? :gerv for this, please clear once confirmed.

(In reply to Gervase Markham [:gerv] from comment #8)
> Note to self: digi is the man to make the DNS changes once we've worked out
> what they are.

Please assign this bug to :jabba when the above questions have been answered. "TYPE257" records are not something we currently guarantee support for, so further work is likely required before :digi (or anyone on our team) can add these DNS records.
Flags: needinfo?(oremj)
Flags: needinfo?(gerv)
I have heard back from Symantec, who have now decided the forms they want to use for their CAA records. AIUI, then, the records that we want (in the format the RFC uses, which I confess I don't entirely understand) are:

$ORIGIN mozilla.org
.       CAA 0 issuewild "symantec.com; brand=geotrust"
.       CAA 0 issuewild "digicert.com"
.       CAA 0 iodef "mailto:security@mozilla.org"

$ORIGIN addons.mozilla.org
.       CAA 0 issue "symantec.com"
.       CAA 0 iodef "mailto:security@mozilla.org"

"CAA" is resource record type 257.

Gerv
Flags: needinfo?(gerv)
oremj: do you have further comment here? If not, we will press on.

Gerv
From my understanding, this just ensures that a flag will be raised if someone tries to request a certificate from another provider?

In that case, yes this is fine. If we discover later that we need to another provider to issue us a cert, I assume we can just add another CAA record?
Flags: needinfo?(oremj)
Yes, and absolutely. And remove any old ones which are no longer relevant.

Gerv
If these records are inaccurate or it doesn't cover all CAs we use, can it cause an outage?
If Mozilla tries to get a new cert (either *.mozilla.org or addons.mozilla.org) from a CA not listed in the records, they have to invoke their "potential risk" process and be very, very careful. So the issuance wouldn't be automated; we might get phone calls, extra checks, that sort of thing, before they issue.

So the only way it could cause an outage is if:

1) A cert expires or is very close to expiry (i.e. our normal renewal methods don't catch it)
2) We decide to renew it from an entirely new supplier at short notice
3) We don't answer the phone or respond to their follow-up enquiries
4) The cert hits expiry, and we don't have a valid *.mozilla.org we can use as temporary cover

It's a pretty rare scenario, and in return, it will make it less likely that we'll get another ComodoGate or Diginotar affecting us.

Gerv
I'm curious to see what Sid and Joe think about this. Also has the RFC moved out of draft status and are we sure it will be implemented?
Yes, it's a proper RFC. Requiring CAs to pay attention to CAA records (which is not the same as saying never issue in contradiction to one) is a potential addition to the Baseline Requirements or Mozilla's root program requirements.

Even if no-one implements, can a couple of DNS records cause problems by themselves?

Gerv
(In reply to Shyam Mani [:fox2mike] from comment #16)
> I'm curious to see what Sid and Joe think about this. Also has the RFC moved
> out of draft status and are we sure it will be implemented?

I would additionally note that, as of 2011, Firefox had chosen not to implement CAA due to its complexity, in favor of an option called DANE. If we are not implementing CAA support in our browser, why are we asking certificate authorities to do otherwise?

"For the time being, while CAA is powerful, it has been determined to be too complicated for this use case. Furthermore, CERT can only specify whole certificates, not just public keys, and is thus too restrictive. Thus, DANE alone will initially be supported."

https://wiki.mozilla.org/Security/DNSSEC-TLS-details

(In reply to Gervase Markham [:gerv] from comment #17)
> Even if no-one implements, can a couple of DNS records cause problems by
> themselves?

Yes, a couple of DNS records can cause problems by themselves.

With SPF, DKIM, DNSSEC, or even in some cases SRV records, it is possible to add a single DNS record that causes a service outage for however long DNS servers cache the erroneous record.
(In reply to Richard Soderberg [:atoll] from comment #18)
> I would additionally note that, as of 2011, Firefox had chosen not to
> implement CAA due to its complexity, in favor of an option called DANE. If
> we are not implementing CAA support in our browser, why are we asking
> certificate authorities to do otherwise?
> 
> "For the time being, while CAA is powerful, it has been determined to be too
> complicated for this use case. Furthermore, CERT can only specify whole
> certificates, not just public keys, and is thus too restrictive. Thus, DANE
> alone will initially be supported."

For a bit of context, I wrote that. It was meant as a statement of scope for that specific project, not as a policy decision for Firefox/Mozilla as a whole. Incidentally, that project has been put on hold indefinitely. Although, there's no reason it can't be revived with an increased scope as long as we have the resources to work on it.
(In reply to David Keeler (:keeler) from comment #19)
> For a bit of context, I wrote that. It was meant as a statement of scope for
> that specific project, not as a policy decision for Firefox/Mozilla as a
> whole. Incidentally, that project has been put on hold indefinitely.
> Although, there's no reason it can't be revived with an increased scope as
> long as we have the resources to work on it.

Apologies, I didn't realize it was a localized project. I haven't been able to find anything otherwise on the Firefox/Mozilla position on these things, so I'd like to restate my question to remove my objection from my prior comment:

Why CAA, rather than CERT and/or DANE (or all three)?

I don't have any opinion on which of these we implement, nor specific objection to CAA, so this isn't meant to bikeshed-derail the bug. Just trying to learn more about the decisions behind this request, so I can understand better.
(In reply to Richard Soderberg [:atoll] from comment #20)

> I don't have any opinion on which of these we implement, nor specific
> objection to CAA, so this isn't meant to bikeshed-derail the bug. Just
> trying to learn more about the decisions behind this request, so I can
> understand better.

+1, this is my approach here too. And yes Gerv, as Richard already mentioned, a couple of incorrect "harmless" entries can end up causing trouble.
(In reply to Shyam Mani [:fox2mike] from comment #16)
> I'm curious to see what Sid and Joe think about this. Also has the RFC moved
> out of draft status and are we sure it will be implemented?

Setting needinfo? flags for this.
Flags: needinfo?(sstamm)
Flags: needinfo?(jstevensen)
We should do this.

The goal here is to use CAA to reduce the chance of mis-issuance (someone getting a mozilla.org cert).  This is not a client-DNS protocol, it's intended to be a CA-DNS protocol.  When a CA receives a request for issuance, it can check DNS to see if it should issue or not.

We've talked about using DANE or repurposing CAA to catch mis-issued certs in Firefox, but I think we're opting to do key pinning instead.  That's orthogonal.

We want to tell CAs who can issue for our domains, just as oremj said in comment 12, so how Firefox works is somewhat irrelevant.  But for clarity, rolling out CAA will not affect how Firefox loads our sites.
Flags: needinfo?(sstamm)
CAA may once have been, but is definitely no longer, a protocol to be implemented by browsers. You may be working on an old understanding of what CAA is. Late here; more tomorrow if necessary. But read the RFC.

Gerv
(In reply to Richard Soderberg [:atoll] from comment #20)
> (In reply to David Keeler (:keeler) from comment #19)
> > For a bit of context, I wrote that. It was meant as a statement of scope for
> > that specific project, not as a policy decision for Firefox/Mozilla as a
> > whole. Incidentally, that project has been put on hold indefinitely.
> > Although, there's no reason it can't be revived with an increased scope as
> > long as we have the resources to work on it.
> 
> Apologies, I didn't realize it was a localized project. I haven't been able
> to find anything otherwise on the Firefox/Mozilla position on these things,
> so I'd like to restate my question to remove my objection from my prior
> comment:
> 
> Why CAA, rather than CERT and/or DANE (or all three)?

In February 2013 at the NIST Conference on Improving Trust in the Online Marketplace, we discussed lots of proposed technologies for addressing various shortcomings in the trust model, and there was consensus that we should consider trying them all out so that we could better determine what worked and what didn't work. Sid Stamm and I were panelists on a talk there.

Last month at the CAB Forum face-to-face meeting in Munich, we discussed CAA and wondered what issues web site owners might encounter in creating their CAA records. I proposed that the browser vendors add their CAA records and report on the experience. That's why Gerv initiated this.
(In reply to Richard Soderberg [:atoll] from comment #18)
> With SPF, DKIM, DNSSEC, or even in some cases SRV records, it is possible to
> add a single DNS record that causes a service outage for however long DNS
> servers cache the erroneous record.

Only if people are actually paying attention to those records. My point was, if no-one implements and checks the records, it can't cause a problem. 

In the case of CAA, there is no risk of a service outage of the SPF/DKIM/DNSSEC "cached info" type - I would expect CAs to bypass all DNS caches when getting CAA info. And they are so rarely accessed that you could set a TTL of 1 second if you wanted without any performance issues. 

There is only a risk of a service outage from not having a cert if a very unlikely set of circumstances comes to pass where multiple systems and processes fail _and_ Mozilla does something dumb (requesting a cert from a new provider) when something not-dumb would be easier and simpler. The chances of a failure specifically from this, as opposed to a general "forgot to renew cert" failure, are almost zero. Whereas the upside is potentially very large, if we have another security breach in the CA system.

So we should go ahead.

To be more clear about CAA: as Sid says, its function is different to DANE and CT (if that's what you mean by CERT). 

It would not, in fact, be even _possible_ to observe CAA in Firefox because the domain owner is only asked to ensure that the records are matching at cert issuance time. They have no obligation to keep them matching throughout the lifetime of the cert. (And this is precisely because the IETF didn't want CAA to duplicate the functions of DANE.) So checking CAA in Firefox would not only be an abuse of the standard, it would lead to many false security alerts.

Gerv
jstevensen: can you comment here?

I'm on PTO next week and it would be great to see movement when I get back :-)

Gerv
(In reply to Richard Soderberg [:atoll] from comment #18)
> I would additionally note that, as of 2011, Firefox had chosen not to
> implement CAA due to its complexity, in favor of an option called DANE.

We did do some experiment with DANE that never shipped. There are no plans to do either DANE or CAA in Gecko. That may change at some point in the future, but it isn't on the roadmap.
Brian: we are never going to do CAA in Gecko, because the final form of CAA makes it unsuitable for implementation in clients. (The CAA record keeper has no obligation to keep their CAA record matching their cert use for the entire lifetime of the cert. http://tools.ietf.org/html/rfc6844 section 3, last para:

"Note that the above restrictions only apply at certificate issue.
   Since the validity of an end entity certificate is typically a year
   or more, it is quite possible that the CAA records published at a
   domain will change between the time a certificate was issued and
   validation by a relying party."

Gerv
I don't have a problem with this, of course this depends on CA's being diligent.
Flags: needinfo?(jstevensen)
Reassigning to :jabba as requested.

Gerv
Assignee: server-ops-webops → jdow
:uberj - Can you add the ability to add CAA records to inventory? Also, need to verify that Akamai can deal with them. Then we can add the appropriate records.
Assignee: jdow → juber
I'm in contact with Akamai and I'm in the process of verifying support for CAA records.
(In reply to Brian Hourigan [:digi] from comment #33)
> I'm in contact with Akamai and I'm in the process of verifying support for
> CAA records.

Forgive my ignorance, but why is Akamai in this picture? CAA records are handled in DNS, and as far as I can tell, mozilla.org is served by ns1.mozilla.org and ns2.mozilla.org, which are both hosted by Mozilla and not outsourced (at least according to their 'A' records)... or am I missing something?
(In reply to Reed Loden [:reed] from comment #34)
> Forgive my ignorance, but why is Akamai in this picture?

We're in the (months-long) process of migrating to Akamai for external DNS hosting.
:digi: any news here?

Gerv
Group: mozilla-corporation-confidential
Group: mozilla-corporation-confidential
To summarise the non-public comments: digi is working with Akamai on this issue.

Gerv
Just an update:

It doesn't look like this is going to be supported soon. It was cited that other commercial DNS providers do not support CAA records and it doesn't seem to be a feature which is in high demand. Our DNS provider understands that someone needs to be first to market with it, but they are hesitant to commit to a date of when it will be available.
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
A contact writes:

We heard from Akamai that they can support CAA records as long as you are doing a zone transfer from your DNS manager to their DNS. I do not know how you are set up and if that would apply, but we did specifically hear about CAA and DANE working in this manner with Akamai."

:digi: is there any further news on whether or when we might be able to do this?

Gerv
Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/111]
Flags: needinfo?(bhourigan)
I just contacted Akamai CCARE and they confirmed CAA records are not supported. Our architecture is setup so Akamai AXFRs data from our BIND based hidden masters. While our side would support the record, their ZTA (zone transfer agent) and proprietary DNS server does not.
Flags: needinfo?(bhourigan)
:digi: OK. Thanks for taking the time to look into this for us. We'll let this bug lie dormant until things maybe change one day.

Gerv
Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/111] → [kanban:https://webops.kanbanize.com/ctrl_board/2/70]
Closing as WONTFIX for now, due to comment 45-46 and our inability to proceed any further here.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
I'd like to reopen this. Word from the CAB Forum is that Akamai may now support CAA. :digi: can you ask again?

Gerv
Status: RESOLVED → REOPENED
Flags: needinfo?(bhourigan)
Resolution: WONTFIX → ---
(In reply to Gervase Markham [:gerv] from comment #48)
> I'd like to reopen this. Word from the CAB Forum is that Akamai may now
> support CAA. :digi: can you ask again?
> 
> Gerv

Will do.
As a general note, I know that we issue from Amazon, Thawte, Geotrust, Symantec, Digicert at the bare minimum under mozilla.org in various places.

:April, can you review this bug and confirm that we're okay to proceed with this from an Infosec perspective?
Flags: needinfo?(april)
Thawte, Geotrust and Symantec have common ownership and I believe there's a CAA value which covers them all - "symantec.com". 

The full list (well, full list which has made it into CT) of certs on mozilla.org is here:
https://crt.sh/?q=%25.mozilla.org

I see issuance from:
Digicert
Geotrust
Verisign (5 instances)
Trustwave (sendto.mozilla.org - presumably outsourced)
Comodo - UTN-USERFirst-Hardware (addons.mozilla.org, www.addons.mozilla.org)
Thawte (aus2-community.mozilla.org, aus3.mozilla.org)
Equifax (aus3.mozilla.org)
Amazon (statics.tls.security.mozilla.org)

While this is a long list, specifying it would cut out lots of the little CAs which might get compromised. And perhaps there are a few certs we could replace here to make the list shorter.

Gerv
Of those, we retain an unused account with Geotrust, and we have no control over the SSL registrar used for sendto.mozilla.org. I'm not familiar with the Verisign certificates personally, but I know we have various browser pins for some of the remainder, and we're actively issuing Amazon/Digicert, and we can't change Thawte/Equifax due to pins.

Can CAA exclude domains that we outsource to other providers, like sendto.mozilla.org?
(In reply to Richard Soderberg [:atoll] from comment #52)
> Of those, we retain an unused account with Geotrust, 

If we plan no new Geotrust issuances, we don't have to add them to the CAA record.

> and we have no control
> over the SSL registrar used for sendto.mozilla.org. 

Assuming we retain control over the DNS there, we can add a record for that subdomain which says that anyone can issue for it.

> I'm not familiar with
> the Verisign certificates personally, but I know we have various browser
> pins for some of the remainder, and we're actively issuing Amazon/Digicert,
> and we can't change Thawte/Equifax due to pins.

Again, records at the subdomain level can account for these things if we want to keep the top-level record restricted to our main issuer(s).

> Can CAA exclude domains that we outsource to other providers, like
> sendto.mozilla.org?

Yes - not via detecting their outsourced status :-), but simply via a subdomain record.

Taking on CAA provides the benefits of perhaps avoiding the "weakest link" problem with CAs (and, given that Mozilla has been the target of misissuance in the past, that's a good thing), but it means we do need to keep more careful track of what CAs we use and make sure the records match at issuance time. (Note: CAA is only ever checked at issuance time, by design.)

If issuance is refused because our CAA records are wrong, we can update them. If we are tracking our certs properly, we really shouldn't be reissuing them close to deadlines anyway. (Clock skew can mean some failures start to occur before expiry.)

Gerv
Akamai CCARE indicates that FastDNS does not support CAA records.
Flags: needinfo?(bhourigan)
I don't see any downside with putting in the CAA records; they seem like all upside to me.  It would be nice if we could pare that list down a bit and possibly force outsourced sites to come back to us for their certificate issuance instead of going to these random one-off third party vendors.

Also, we should probably add Let's Encrypt to the list as well.
Flags: needinfo?(april)
While we support LE as an organization, if we aren't using them for our certs, we shouldn't be adding them to our CAA. A new CA which does automated issuance does have a different risk profile.

Still, perhaps this is all academic if Akamai still can't yet support us. I've passed on this lack of support to people in the CAB Forum interested in CAA, who might try and put some pressure on. We should try and apply what we can, as well.

Gerv
I used LE on a ___.mozilla.org last month to work around a production emergency issue, and we have promised people that they are permitted to self-issue Let's Encrypt for any Mozilla property they self-manage, so it's absolutely something I'd want to include here.

But, the lack of Akamai support means we're not going to proceed any further for now. Gerv, do you mind if we re-close for now?
Yep, we can resolve it for now. I'll reopen if I hear news that support might have arrived.

Gerv
Status: REOPENED → RESOLVED
Closed: 9 years ago → 8 years ago
Resolution: --- → INCOMPLETE
See Also: → 1251768
I'm in the process of having our domains removed from letsencrypt's blacklist so that we can begin issuing letsencrypt certs (I'm not entirely sure how :atoll was able to issue a ___.mozilla.org certificate from letsencrypt in Comment 57 , given the blacklist, perhaps at that time it did not include subdomains but now does).

Letsencrypt uses CAA records to determine what to disallow. I'd like to render the resulting blacklisted domains into CAA records, per letsencrypt's request.

Would Infrastructure Engineering & Operations contact Akamai Ccare again and find out if their enhanced DNS product supports CAA records yet and if not what the timeline is on their side for support of CAA?

Ticket on getting us removed from the letsencrypt blacklist : Bug 1271005
Ticket on getting the letter drafted to letsencrypt : Bug 1300195
Status: RESOLVED → REOPENED
Flags: needinfo?(bhourigan)
Resolution: INCOMPLETE → ---
The exclusion didn't cover mozilla.*.*, only mozilla.*
And here was the status 6 months ago of Akamai support : https://bugzilla.mozilla.org/show_bug.cgi?id=1251768#c17
I talked to :atoll and found that what he meant in Comment 57 is that he created a letsencrypt cert for ___.mozilla.org.uk (not ___.mozilla.org) which isn't blacklisted by letsencrypt (likely because it's not in the alexa top 1000)
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/70] → [kanban:https://webops.kanbanize.com/ctrl_board/2/3448]
I have a call with the product manager of FastDNS next week, and I'll find out where we're at with it.
Assignee: juber → server-ops-webops
(In reply to Brian Hourigan [:digi] from comment #63)
> I have a call with the product manager of FastDNS next week, and I'll find
> out where we're at with it.

Our TAM mentioned:

"In fact it got implemented after Mozilla showed interest previously. We have support for generic record types as specified by RFC 3597."

However, inventory doesn't support RFC 3597. While we're unblocked by one hurdle we're blocked by another. The good news is that inventory is EOL and we'll be migrating to something else soon. Please NI cshields for timing on that.
Flags: needinfo?(bhourigan)
Assignee: server-ops-webops → infra
Component: WebOps: Other → Infrastructure: DNS
QA Contact: nmaul → cshields
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/3448]
Corey,
   What is the timeline for migrating from our existing inventory solution to the next thing, specifically the aspect of inventory which manages our DNS zones. Currently inventory doesn't support CAA records which we need to be able to control/constrain what domains certificate authorities can issue certs for.
Flags: needinfo?(cshields)
Corey writes in IRC

    egads that's tough..  was supposed to be this year but we can never get it scheduled from the servicenow side to prioritize.  Will start POC'ing infoblox and servicenow integration next Q so "sometime next year", I'm hesitant to commit because it was supposed to be "sometime this year{"

Corey suggested asking rtucker for how we can add DNS records to our DNS zones without using inventory. :rtucker, any ideas?
Flags: needinfo?(cshields) → needinfo?(rtucker)
If the zone is managed by inventory, you cannot manage them by hand unfortunately
Flags: needinfo?(rtucker)
See Also: → 1331257
Perhaps it's time to patch Inventory:

https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum

Unless timelines for Infoblox->Akamai, with confirmed CAA support (?), have become more clear?
Flags: needinfo?(cshields)
Note that CAA is not mandatory for _sites_, it's mandatory for CAs to check for record presence. However, this does of course significantly increase the value proposition of having a record.

Gerv
EIS has been asking us to ship this, too. We're kind of low on good reasons not to schedule it for this year.
:atoll have you heard if Infoblox->Akamai timelines are now known or does only Corey know?
Flags: needinfo?(rsoderberg)
I emailed :atoll asking.
I have no authoritative information on this subject. Please escalate to the product owner of Akamai for further information.
Flags: needinfo?(rsoderberg)
Akamai supports CAA records, however, our DNS management software (inventory) does not. We're migrating to Infoblox later this year. Our first planning session is in early September, I think this is slated to be complete before the end of Q4. NI'ing rtucker to confirm IB can support TYPE257/CAA.
Flags: needinfo?(rtucker)
According to:

https://community.infoblox.com/t5/Security/NIOS-support-for-CAA-records-RFC-6844/td-p/9655

Infoblox doesn't support CAA.

I've opened a support case with InfoBlox for an official statement from the vendor.
Flags: needinfo?(rtucker)
:rtucker, what was Infoblox response?
Flags: needinfo?(rtucker)
Response is no current support, and I haven't heard back from the product team on the timeline. I'll send a followup email today.
Flags: needinfo?(rtucker)
I received word, Q1 2018 for CAA support
(In reply to Gene Wood [:gene] from comment #65)
>    What is the timeline for migrating from our existing inventory solution
> to the next thing, 

We are targeting Q1 next year for our DNS/DHCP migrations, after which this should be feasible.
Flags: needinfo?(cshields)
Infoblox DNS/DHCP migration was successful. CAA record support is available beginning in NIOS 8.3. NIOS 8.2.4 is the latest stable version available. NIOS 8.3.0 EA 2 is available to us, but it may not be fully supported.
Assuming 8.3.0 goes GA within a few months, and that we intend to deploy it to our instance once it's available, no need to rush into an unsupported configuration solely for this task.
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/19/6903]

moved to CORE-821 for mozilla.org/.com - product is tracking this in 1519560

Status: REOPENED → RESOLVED
Closed: 8 years ago → 4 years ago
Resolution: --- → INVALID

Some links to get to these tickets :

I've written up a summary page that gives the background to all of this : Certificate Authority Authorization CAA including Let's Encrypt

See Also: → 1519560
You need to log in before you can comment on or make changes to this bug.