Create and delegate and eucalyptus.internal zones



6 years ago
5 years ago


(Reporter: gozer, Assigned: bhourigan)




(1 attachment)



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:


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 :


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

[root ~]# dig @ but not available

;	IN	A


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.


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 zone delegated is a must, 'eucalyptus.internal', would be nice, but I am open to discussion.


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.

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.


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


6 years ago
Assignee: server-ops-infra → bhourigan

Comment 3

6 years ago
Ping ?

Comment 4

6 years ago
I've applied the patch for, 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 or similar?

Comment 5

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

They are now:

Could you make that change?

For testing, the following entry should be resolvable

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 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 vlan.

For internal IPs, they come from the unrouted 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.

Comment 7

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

zone "" {
  type forward;
  forward only;
  forwarders {;;

Comment 8

6 years ago
Thanks for clarifying. I went ahead and configured, eucalyptus.internal, and 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


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