Opened 10 years ago

Closed 10 years ago

#11 closed (fixed)

define full reverse and forward zones for BBN rack's public IPs

Reported by: Owned by:
Priority: major Milestone: EG-ADM-1
Component: Administration Version: SPIRAL4
Keywords: Cc:


All public IP addresses in use by the BBN rack (non-gateway/broadcast addresses in the subnet) should resolve in DNS to something reasonable. This doesn't need to be up-to-date per-experiment, but DNS should report at a glance whether a given IP address belongs to an infrastructure device (and which one), or whether it is reserved for OpenStack or bare metal experimental use.

Change History (14)

comment:1 Changed 10 years ago by

Last known status: Victor is compiling a list of which IPs are being used for what.

comment:2 Changed 10 years ago by

Milestone: EG-ADM-1

Updating the milestone field of this ticket to note that it is blocking testing of EG-ADM-1 step 2.

comment:3 Changed 10 years ago by

Owner: changed from to

Question: should the forward entries be managed as belonging to BBN's domain or ExoGENI domain (one should have the primary responsibility and the other can have CNAMEs?

comment:4 Changed 10 years ago by

My vote is for BBN's domain because we manage the reverse zone, so it is more likely that the forward and reverse will stay in sync if we do it that way. But i don't feel strongly. I agree that whoever is secondary should $GENERATE a set of CNAMEs to the other.

comment:5 Changed 10 years ago by

Hmm, actually, having typed that and clicked submit, in fact i think we both have to maintain a full list because the CNAMEs will be things like bbn-hn or openstack-worker-32, so they'll have to be enumerated individually (as opposed to a PTR domain, which would actually work with a full-subnet $GENERATE). Anyway, i had been assuming we'd be primary (and i think Chris and i agreed that months ago), but if all the entries are correct, i really don't think it makes very much difference. Do you have a preference?

comment:6 Changed 10 years ago by

For the record, according to, which we were discussing in 20, the hostname for the SSG5 should be bbn-ssg. (Since that's a public IP,, it will fall under this ticket.)

comment:7 Changed 10 years ago by

Sigh, i meant 22. Did i say "long week"? :>)

comment:8 Changed 10 years ago by

Ping. This is still blocking EG-ADM-1.

comment:9 Changed 10 years ago by

Owner: changed from to

comment:10 Changed 10 years ago by

Reminder: this ticket (defining full IP-to-hostname mappings for the public IPs in the BBN rack control subnet) is still blocking EG-ADM-1.

comment:11 Changed 10 years ago by

Victor just proposed the following forward zone for, on IRC:

# Gateway and servers
ctrl-gw              IN  A
bbn-ssg              IN  A
bbn-hn               IN  A
bbn-8052             IN  A

# VMs
bbn-vm-005           IN  A
bbn-vm-104           IN  A

# Spares
bbn-unassigned-105   IN  A
bbn-unassigned-109   IN  A

# Bare-metal nodes
bbn-bare-110         IN  A
bbn-bare-111         IN  A

# More spares
bbn-unassigned-112   IN  A
bbn-unassigned-126   IN  A

Victor, does this look like what you said?

comment:12 Changed 10 years ago by

Exactly. Once the A records are defined, I'll complete the CNAMEs for

comment:13 Changed 10 years ago by

Here's our zone file section that does the A records (PTR records are similar):

ctrl-gw.exogeni        IN      A
bbn-ssg.exogeni        IN      A
bbn-hn.exogeni         IN      A
bbn-8052.exogeni       IN      A

$GENERATE 5-9     bbn-vm-00$.exogeni       IN  A 192.1.242.$
$GENERATE 10-99   bbn-vm-0$.exogeni        IN  A 192.1.242.$
$GENERATE 100-104 bbn-vm-$.exogeni         IN  A 192.1.242.$
$GENERATE 105-109 bbn-unassigned-$.exogeni IN  A 192.1.242.$
$GENERATE 110-111 bbn-bare-$.exogeni       IN  A 192.1.242.$
$GENERATE 112-126 bbn-unassigned-$.exogeni IN  A 192.1.242.$

That should be live now. Over to you.

comment:14 Changed 10 years ago by

Resolution: fixed
Status: newclosed

Victor implemented the CNAMEs for all these items, and i checked a representative subset. So i think we're all set here. Thanks.

Note: See TracTickets for help on using tickets.