1238523 - please make https://bmoattachments.org/ work

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Infrastructure, defect)

Description

[:glob ✱]

trying to visit https://bmoattachments.org/ fails due to a missing dns entry.

in order to get hsts preloading working in a sane way we'd like for this to resolve and serve files.  see bug 1237180 for details of what we're doing.

access https://bmoattachments.org/ should redirect to https://bugzilla.mozilla.org/ and we'd like a zero byte file returned by https://bmoattachments.org/hstsping with the following sts header:

Strict-Transport-Security: max-age=15552000; includeSubDomains; preload


thanks!

Comment 1

[April King [:April]]

You'll probably always want to have a long cache-control header set on the image.  Shorter than the HSTS max-age, but sufficient that it's not constantly probing the root domain for this file.

Comment 2

[Kendall Libby [:fubar] (he/him)]

I've created an A record for bmoattachments.org so that https://.../ will work. Note, however, that when we fail over to AWS there will be an extra step and a delay in its DNS updating (or worse, if SCL3 is completely offline).

We can't CNAME bmoattachments.org like we do bugzilla.mozilla.org because bmoattachments.org has NS records, e.g. http://support.simpledns.com/kb/a94/why-cant-i-create-a-cname-record-for-the-zone-name-itself.aspx

Any chance we can use www.bmoattachments.org instead?

Comment 3

[:glob ✱]

(In reply to Kendall Libby [:fubar] from comment #2)
> Any chance we can use www.bmoattachments.org instead?

yeah - that should work.  (disclaimer: pre-coffee).

Comment 4

[Reed Loden [:reed]]

No, has to be https://bmoattachments.org/, as it needs to be on the apex so that HSTS will affect all subdomains.

Comment 5

[April King [:April]]

It also has to be on the apex if we want to add bmoattachments.org to the HSTS preload list. As :reed said, it can't be on www.bmoattachments.org.  If all the sites were hosted as bug1238523.www.bmoattachments.org, includeSubDomains would still get them, but unfortunately they are not.

Comment 6

[:Atoll]

If the ping URL goes down for up to 3 days at a time, does that have any impact on the HSTS Preload project? What's their general ping interval for the preload entry to remain valid?

I don't think this needs to be migrated to AWS during an outage, it just has to work most of the time so that the preload list keeps us on it, right?

Comment 7

[April King [:April]]

Not sure, but I can email @lgarron and ask?

Comment 8

[:Atoll]

Yeah. I think in this case we can just say "this will work when SCL3 is up, and fail when SCL3 is down", and that's probably sufficient for the preload request to have the desired result. If, somehow, they refuse our preload request, we resubmit and try again - but I would imagine the form checks *at submission time*, if nothing else. So it should be fine to just single-home this from SCL3 or wherever for the long-term.

Comment 9

[Kendall Libby [:fubar] (he/him)]

ok, all set. take a look and see if that matches expectations?

Comment 10

[Reed Loden [:reed]]

(In reply to Richard Soderberg [:atoll] from comment #6)
> If the ping URL goes down for up to 3 days at a time, does that have any
> impact on the HSTS Preload project? What's their general ping interval for
> the preload entry to remain valid?
> 
> I don't think this needs to be migrated to AWS during an outage, it just has
> to work most of the time so that the preload list keeps us on it, right?

Chrom(e|ium) doesn't monitor sites to keep things on the HSTS preload list, but Firefox does (incorrectly, I feel). If the site happens to be offline or not reachable on the Saturday or Sunday when HSTS preloads are sync'd, it will be removed from Firefox's preload list.

(In reply to Kendall Libby [:fubar] from comment #9)
> ok, all set. take a look and see if that matches expectations?

https://bmoattachments.org/hstsping looks good from a header perspective (but I'm getting a weird error), but can you also make https://bmoattachments.org/ return the header as well (the 301 is fine, just needs to have the header sent with it). Otherwise, Firefox will never add the domain to the preload list, as it won't detect it on the apex.

The weird error I mention is this:

$ curl https://bmoattachments.org/hstsping
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>200 OK</title>
</head><body>
<h1>OK</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator,
 [e-mail] and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
</body></html>

Comment 11

[:Atoll]

(In reply to Reed Loden [:reed] (use needinfo?) from comment #10)
> (In reply to Richard Soderberg [:atoll] from comment #6)
> > If the ping URL goes down for up to 3 days at a time, does that have any
> > impact on the HSTS Preload project? What's their general ping interval for
> > the preload entry to remain valid?
> > 
> > I don't think this needs to be migrated to AWS during an outage, it just has
> > to work most of the time so that the preload list keeps us on it, right?
> 
> Chrom(e|ium) doesn't monitor sites to keep things on the HSTS preload list,
> but Firefox does (incorrectly, I feel). If the site happens to be offline or
> not reachable on the Saturday or Sunday when HSTS preloads are sync'd, it
> will be removed from Firefox's preload list.

Where can we see the code implementing this logic as described?

> (In reply to Kendall Libby [:fubar] from comment #9)
> > ok, all set. take a look and see if that matches expectations?
> 
> https://bmoattachments.org/hstsping looks good from a header perspective
> (but I'm getting a weird error), but can you also make
> https://bmoattachments.org/ return the header as well (the 301 is fine, just
> needs to have the header sent with it). Otherwise, Firefox will never add
> the domain to the preload list, as it won't detect it on the apex.

How many Mozilla domains do we exclude from the upstream preload list as a result of this apex test?

Comment 12

[Kendall Libby [:fubar] (he/him)]

(In reply to Reed Loden [:reed] (use needinfo?) from comment #10)
>
> https://bmoattachments.org/hstsping looks good from a header perspective
> (but I'm getting a weird error), 

Fixed.

> but can you also make
> https://bmoattachments.org/ return the header as well (the 301 is fine, just
> needs to have the header sent with it). Otherwise, Firefox will never add
> the domain to the preload list, as it won't detect it on the apex.

And added.

Comment 13

[April King [:April]]

Hey, this looks really great!  I'd request that we update the number -- sorry for noticing this earlier -- to bring it in line with BMO.  That is, a max-age of 31536000:

max-age=31536000; includeSubdomains; preload

But I will say that everything seems like it's working great with bmoattachments.org.  I really appreciate everybody's hard work on this!

Comment 14

[Kendall Libby [:fubar] (he/him)]

(In reply to April King from comment #13)
> Hey, this looks really great!  I'd request that we update the number --
> sorry for noticing this earlier -- to bring it in line with BMO.  That is, a
> max-age of 31536000:

done.