If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

DNS: diresworb.org point to browserid-stage1.vm1.labs.sjc1.mozilla.com



Infrastructure & Operations
6 years ago
4 years ago


(Reporter: Lloyd Hilaiel, Assigned: XioNoX)





6 years ago
this can be taken live/made publicly visible immediately.


6 years ago
Blocks: 673974

Comment 1

6 years ago
changed from beta.browserid.org to diresworb.org to keep beta code off a subdomain of production.
Summary: DNS: beta.browserid.org point to browserid-stage1.vm1.labs.sjc1.mozilla.com → DNS: diresworb.org point to browserid-stage1.vm1.labs.sjc1.mozilla.com

Comment 2

6 years ago
confidential because ticket contains a domain name not yet registered.  kinda paranoid, whatever.
Group: mozilla-corporation-confidential
Depends on: 674652


6 years ago
Group: mozilla-corporation-confidential
So, this is live, but not resolving from everywhere it should. Moving over to netops to sort out why this is the case.

Resolves from the internet, not from

My changes were svn r18223, but the slave config scripts didn't do anything, so I think that's missing.
Assignee: server-ops-labs → network-operations
Component: Server Operations: Labs → Server Operations: Netops
QA Contact: zandr → mrz
Duplicate of this bug: 674034

Comment 5

6 years ago
From where I sit it resolves fine:

[lth@lloydpro browserid]$ dig diresworb.org | egrep ^diresworb
diresworb.org.		300	IN	A

but the load balancer doesn't seem to want to talk to me.

[lth@lloydpro browserid]$ curl
curl: (7) couldn't connect to host


Comment 6

6 years ago

Hi!  Any chance we could get a little love for this bug?  It's making some people that I would prefer to be happy, sad.

Thank you, and sorry to nag,

Comment 7

6 years ago
The first problem is a DNS misconfiguration/bug that is now fixed.

For the second, my curl says everything is good, from both my work computer and and my personal server.
Could you please check again, maybe also with a wget --no-check-certificate https://diresworb.org/
a traceroute to that IP and/or a telnet 443 for example.

Assignee: network-operations → arzhel
This is what I see:
$ curl
curl: (51) SSL: certificate subject name '*.diresworb.org' does not match target host name ''

From my Mac w/ and w/o VPN-MPT

$ wget --no-check-certificate https://diresworb.org/
gets me this (still using VPN MPT):
--2011-08-05 16:16:04--  https://diresworb.org/
Resolving diresworb.org...
Connecting to diresworb.org||:443... connected.
WARNING: certificate common name `*.diresworb.org' doesn't match requested host name `diresworb.org'.
HTTP request sent, awaiting response... 200 OK
Length: 1991 (1.9K) [text/html]
Saving to: `index.html'

100%[==================================================================================================>] 1,991       --.-K/s   in 0s      

2011-08-05 16:16:04 (22.7 MB/s) - `index.html' saved [1991/1991]
(In reply to James Bonacci [:jbonacci] from comment #8)

> WARNING: certificate common name `*.diresworb.org' doesn't match requested
> host name `diresworb.org'.

True, but unimportant. diresworb.org is in the SubjAltName of the cert. Why wget doesn't look at this is beyond me.

Comment 10

6 years ago
Is there still something wrong here, or can I close the bug?
As far as I can tell, everything is working as it should. I can access Beta from within Mozilla and outside Mozilla. Please close.

Comment 12

6 years ago
per comment 11
Last Resolved: 6 years ago
Resolution: --- → FIXED
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.