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

[chaos@bbn.com]

All public IP addresses in use by the BBN rack (non-gateway/broadcast addresses in the 192.1.242.0/25 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.

[chaos@bbn.com]

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

[chaos@bbn.com]

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

[ibaldin@renci.org]

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?

[chaos@bbn.com]

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.

[chaos@bbn.com]

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?

[chaos@bbn.com]

For the record, according to ​https://wiki.exogeni.net/doku.php?id=public:hardware:rack_layout, which we were discussing in 20, the hostname for the SSG5 should be bbn-ssg. (Since that's a public IP, 192.1.242.2, it will fall under this ticket.)

[chaos@bbn.com]

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

[chaos@bbn.com]

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

[chaos@bbn.com]

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.

[chaos@bbn.com]

Victor just proposed the following forward zone for exogeni.gpolab.bbn.com, on IRC:

# Gateway and servers
ctrl-gw              IN  A  192.1.242.1
bbn-ssg              IN  A  192.1.242.2
bbn-hn               IN  A  192.1.242.3
bbn-8052             IN  A  192.1.242.4

# VMs
bbn-vm-005           IN  A  192.1.242.5
...
bbn-vm-104           IN  A  192.1.242.104

# Spares
bbn-unassigned-105   IN  A  192.1.242.105
...
bbn-unassigned-109   IN  A  192.1.242.109

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

# More spares
bbn-unassigned-112   IN  A  192.1.242.112
...
bbn-unassigned-126   IN  A  192.1.242.126

Victor, does this look like what you said?

[vjo@duke.edu]

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

[chaos@bbn.com]

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

ctrl-gw.exogeni        IN      A       192.1.242.1
bbn-ssg.exogeni        IN      A       192.1.242.2
bbn-hn.exogeni         IN      A       192.1.242.3
bbn-8052.exogeni       IN      A       192.1.242.4

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

[chaos@bbn.com]

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