Create and delegate eucalyptus.mozillalabs.com and eucalyptus.internal zones

RESOLVED FIXED

Status

RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: gozer, Assigned: bhourigan)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
To enable Eucalyptus DNS support, for HA and to provide instances with nice hostnames, it's necessary to let eucalyptus act as the DNS server for 2 zones:

'eucalyptus.mozillalabs.com'
and
'eucalyptus.internal'

This bug is to request the creation of these zones in the existing internal DNS inrastructure, so that requests to these zones get forward to the labs eucalyptus cluster in SCL3.

The 2 nameservers over there are :

euca0 10.22.111.5
euca1 10.22.111.50

And are currently up and running, and answering queries already. i.e.

[root ~]# dig eucalyptus.mozillalabs.com @10.22.111.5 but not available

;; QUESTION SECTION:
;eucalyptus.mozillalabs.com.	IN	A

;; ANSWER SECTION:
eucalyptus.mozillalabs.com. 20	IN	A	10.22.111.5

I realize that the eucalyptus.internal. zone is a bit trickier, naming wise, as it's pretty global.

The reason for that one is to that instance themselves can get a private hostname, i.e.

euca-10-33-22-232.eucalyptus.internal

That zone itself, since it's only really going to be accessed from inside the eucalyptus network itself, could be considered optionnal.

In that case, I would end up having to run my own nameservers *inside* the eucalyptus cluster, just to serve that one zone.

Opinions/question most welcome.

But in short, getting the eucalyptus.mozillalabs.com zone delegated is a must, 'eucalyptus.internal', would be nice, but I am open to discussion.

Thanks.
(Reporter)

Comment 1

6 years ago
Forgot to make the internal-only nature of these zones clear. This is strickly for the internal network, not internet-public at all.

This is so joe developer from his desk in MV can lookup the names of his/her eucalyptus instance.

None of this is meant to be internet available.
(Reporter)

Comment 2

6 years ago
Created attachment 675758 [details] [diff] [review]
DNS Patch

And to make myself clearer, here is what I believe would be a required dnsconfig patch.

Updated

6 years ago
Assignee: server-ops → server-ops-infra
Component: Server Operations → Server Operations: Infrastructure
QA Contact: shyam → jdow

Updated

6 years ago
Assignee: server-ops-infra → bhourigan
(Reporter)

Comment 3

6 years ago
Ping ?
(Assignee)

Comment 4

6 years ago
I've applied the patch for eucalyptus.mozillalabs.com, but the TLD .internal currently isn't in use anywhere. I can only find documentation saying euca-A.B.C.D.eucalyptus.<subdomain>, can subdomain be eucalyptus.ml.c or similar?

http://open.eucalyptus.com/wiki/DynamicDNSGuide
(Reporter)

Comment 5

6 years ago
Thanks, but the nameserver changed IPs since I filed this bug, because of VLAN changes.

They are now:
 - 10.22.116.5
 - 10.22.116.6

Could you make that change?

For testing, the following entry should be resolvable

euca-10-22-116-103.eucalyptus.mozillalabs.com
(Reporter)

Comment 6

6 years ago
(In reply to Brian Hourigan [:digi] from comment #4)
> [...] but the TLD .internal
> currently isn't in use anywhere. I can only find documentation saying
> euca-A.B.C.D.eucalyptus.<subdomain>, can subdomain be eucalyptus.ml.c or
> similar?

It's actually a bit of an annoying feature of Eucalyptus, that isn't changeable/configurable yet.

Each instance gets allocated two IPs, one for public consumption, and one internal-only address for intra-VM communications.

In our setup, for instance, euca-A.B.C.D.eucalyptus.<subdomain> represents public IPs in the 10.22.116.0 vlan.

For internal IPs, they come from the unrouted 10.33.0.0 network and get allocated DNS names like euca-A-B-C-D.internal, and unfortunately, the <.internal> bit is not yet changeable/configurable.

The only use case for these DNS entries is for host to talk to each other via a DNS name instead of pure IP addresses.

It's not dramatic, and isn't that important. I've filed a bug upstream @Eucalyptus to make it configurable.
(Reporter)

Comment 7

6 years ago
Also, just realized my initial patch didn't include the reverse zone:

zone "116.22.10.in-addr.arpa" {
  type forward;
  forward only;
  forwarders {
    10.22.116.5;
    10.22.116.6;
  };
};
(Assignee)

Comment 8

6 years ago
Thanks for clarifying. I went ahead and configured eucalyptus.mozillalabs.com, eucalyptus.internal, and 116.22.10.in-addr.arpa to forward to 10.22.116.[56]. It requires some flows to be in place before it will work. I've filed 827438 to track that.
Depends on: 827438
(Assignee)

Updated

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