Closed Bug 883221 Opened 12 years ago Closed 12 years ago

Need a sane process for managing CNAME entries for *.developer.mozilla.org subdomains

Categories

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

Product:
Infrastructure & Operations
Component:
DNS and Domain Registration
Platform:
x86
macOS
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: lorchard, Unassigned)

References

Details

Quick background: For MDN and bug 861981, we're considering embracing Mozilla-related documentation published via 3rd party services like GitHub Pages and ReadTheDocs.org. One of the features offered by both the above is pointing a CNAME at their servers, thus controlling the domain name of URLs. This is desirable for many reasons: common branding; docs can later be moved onto our own servers without breaking links (eg. bug 882919 and bug 882920); etc etc. I can imagine dozens of projects fitting into this scenario. My thought is that we could offer MDN subdomains - for example: * shumway.developer.mozilla.org * firefox-marketplace-api.developer.mozilla.org So, what I'm looking for is help & feedback such as: * Is this a terrible, horrible idea - and if so why, and what might be better? * How do we get these CNAME subdomains set up - eg. file a bug for each one as they come? * Is filing & resolving a bug for each CNAME onerous enough that we could look into something automated & self-service and less demanding of valuable human time? (Or is that premature optimization?) Thanks!
Jake - can you help us decide if this bug is in the right product & component? Should we move it to webops and let you all file the necessary infra bugs?
Flags: needinfo?(nmaul)
Adding a sec-review flag and NEEDINFO on someone OpSec. I'm mildly concerned that CNAME'ing something in a subdomain might have implications with respect to cookies and/or SSL. Maybe I'm crazy and way off base. :) Apart from security concerns, I don't have any particular problem with the basic idea here. Filing bugs is the best way forward. They should go to webops, at least for now, because webops can have the context to know that these are expected and not a problem (SREs/oncall could certainly do them, but it would probably raise a red flag for them, not knowing what's going on, and it would therefore take longer). If you have a bunch to do at once, a single bug for all of them is fine... no need to make separate bugs. But, let's not scope-creep the same bug with additional comments over time. :) We do have internal improvements to our DNS management infrastructure which makes DNS changes easier on us. There's currently no intention to make that self-service... that'd be a bigger project, and should be considered out-of-scope here, I think.
Flags: sec-review?
Flags: needinfo?(nmaul)
Flags: needinfo?(gdestuynder)
Flags: needinfo?(gdestuynder)
The main concern I have is that we don't control the sites that are under a mozilla.org domain when its redirected. I suspect this is ok, but joes knows more about this kind of processes.
Flags: needinfo?(jstevensen)
Flags: sec-review? → sec-review?(jstevensen)
We've allowed this in the past, for sites such as service-now, and others that I can't recall at the moment. However, we've reviewed these requests on a case by case basis and will continue to do so.
Flags: needinfo?(jstevensen)
What CNAMES do you wish to create?
(In reply to Joe Stevensen [:joes] from comment #5) > What CNAMES do you wish to create? No idea, yet. There could be dozens. That's what this bug is about: Working out the process to create them as the need arises, one MDN subdomain per Mozilla project with documentation. I pasted some hypothetical examples in comment #0, but I wanted to sort out this process before we started reaching out to projects at Mozilla to join their docs with MDN.
For example, here are two subdomains, paired with where the docs live now: Before: http://mozilla.github.io/shumway/ (on GitHub Pages) After: shumway.developer.mozilla.org (an MDN CNAME) Before: https://firefox-marketplace-api.readthedocs.org/en/latest/ (on ReadTheDocs) After: firefox-marketplace-api.developer.mozilla.org (an MDN CNAME) Like I said, these are hypotheticals. There are more, but none of the projects have been contacted about this yet.
No activity here for awhile. Not sure about the current consensus, but we'd like to keep this moving so we can implement soon. More grist for the mill, though... What about just using mod_proxy + mod_rewrite on Apache to "mount" these 3rd party sites, at least temporarily until/unless we have our own on-premises publishing infrastructure. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=882927#c2
My primary concern with CNAME'ing third party sites to our domain is the data sharing aspect. We should make the assumption that after this change, any of the subdomains can perform 2-way communication with developer.mozilla.org . This can be accomplished either through postMessage + document.domain or Flash objects + localConnection. Any assumptions that MDN makes regarding redirects may no longer be true as well, e.g. if MDN has a whitelist to only allow redirects to developer.mozilla.org, the subdomains may fall in this category. There is also some risk with sharing cookies since the CNAME sites can set / receive cookies for their parent domains, e.g. foo.developer.mozilla.org can set and will receive cookies for .developer.mozilla.org and .mozilla.org . [1] Overall I think the risk to MDN is low. MDN uses Persona for login which will protect user credentials barring some kind of phishing attack. Crossdomain communication between MDN and third party sites doesn't expose anything that isn't currently exposed. Any attacks against the admin interface can already be performed creating a malicious page on MDN. There is some concern if the third party sites are not as vigilant as we are in protecting against malicious content. [1] - http://tools.ietf.org/html/rfc6265
Les, Given David's concerns, what do you want to do at this point?
Flags: sec-review?(jstevensen)
(In reply to Joe Stevensen [:joes] from comment #10) > Les, > > Given David's concerns, what do you want to do at this point? What I mentioned in Comment 8 is what I want to do. It sounds like the risk is not huge, so... can we go ahead?
Marking this invalid, because we're not going to use subdomains for this work.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.