the FQDN of an OpenVZ resource is not entered into DNS

[chaos@bbn.com]

The full information about my experiment (from ​https://boss.utah.geniracks.net/showexp.php3?experiment=952#details) shows:

Virtual Node Info:
ID              Type         OS              Qualified Name
--------------- ------------ --------------- --------------------
phys1 (pc2)     pc           FEDORA15-STD    phys1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net
virt1 (pc3)     pcvm         OPENVZ-STD      virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net

Of those, the phys1 address is in DNS, and is a valid way to get into the node:

capybara,[~],08:19(0)$ host phys1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net
phys1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net is an alias for pc2.utah.geniracks.net.
pc2.utah.geniracks.net has address 155.98.34.12

However, the virt1 address is not in DNS:

capybara,[~],08:19(0)$ host virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net
Host virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net not found: 3(NXDOMAIN)

Should it be?

[chaos@bbn.com]

Leigh said on 30 May:

The reason you do not see a DNS entry back at bbn is that VMs currently get
non-routable ip addresses. We *do* publish a local DNS entry so that they
resolve from other nodes at the same AM.

There is a todo item to allow for using routable IP addresses, but that has
not been completed yet.

I need to test this and verify where i can resolve the OpenVZ resource's FQDN.

[chaos@bbn.com]

Okay: so indeed, after i got DNS client tools, i found that this lookup works within a container:

[chaos@virt1 ~]$ host virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net
virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net is an alias for pcvm5-1.utah.geniracks.net.
pcvm5-1.utah.geniracks.net has address 172.17.5.1

though the reverse lookup does not work:

[chaos@virt1 ~]$ host 172.17.5.1
Host 1.5.17.172.in-addr.arpa. not found: 3(NXDOMAIN)

The downside of the reverse lookups not working is that control network arp tables are not as informative as they could be:

[chaos@virt1 ~]$ ping virt2.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net
PING pcvm5-2.utah.geniracks.net (172.17.5.2) 56(84) bytes of data.
64 bytes from 172.17.5.2: icmp_req=1 ttl=64 time=923 ms
64 bytes from 172.17.5.2: icmp_req=2 ttl=64 time=0.028 ms
64 bytes from 172.17.5.2: icmp_req=3 ttl=64 time=0.027 ms
^C
--- pcvm5-2.utah.geniracks.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.027/307.999/923.942/435.537 ms

[chaos@virt1 ~]$ /sbin/arp -a
? (172.17.5.2) at 00:01:ac:11:05:03 [ether] on eth999
pc5.utah.geniracks.net (155.98.34.15) at 00:01:ac:11:05:03 [ether] on eth999
boss.utah.geniracks.net (155.98.34.4) at 00:01:ac:11:05:03 [ether] on eth999
virt2-virt1-virt2-0 (10.10.1.2) at 02:00:83:cf:e6:09 [ether] on mv3.3

Things look similar on the OpenVZ host (pc5) itself:

vhost1,[~],12:20(0)$ host virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net
virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net is an alias for pcvm5-1.utah.geniracks.net.
pcvm5-1.utah.geniracks.net has address 172.17.5.1

vhost1,[~],12:26(0)$ host 172.17.5.1
Host 1.5.17.172.in-addr.arpa. not found: 3(NXDOMAIN)

Likewise, it would be nice for the reverse lookups to work, so that the host could get information from its arp table:

vhost1,[~],12:26(1)$ arp -a
ops.utah.geniracks.net (155.98.34.5) at 00:00:9b:62:24:e0 [ether] on eth0
? (172.17.5.3) at 00:00:ac:11:05:03 [ether] on veth3.999
? (155.98.34.1) at 00:d0:bc:f4:14:f8 [ether] on eth0
? (172.17.5.1) at 00:00:ac:11:05:01 [ether] on veth1.999
boss.utah.geniracks.net (155.98.34.4) at 00:00:9b:62:24:df [ether] on eth0
? (172.17.5.4) at 00:00:ac:11:05:04 [ether] on veth4.999
? (172.17.5.2) at 00:00:ac:11:05:02 [ether] on veth2.999

The lookups are not restricted to the host which is hosting the container in question: on pc3:

vhost2,[~],12:32(0)$ host virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net
virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net is an alias for pcvm5-1.utah.geniracks.net.
pcvm5-1.utah.geniracks.net has address 172.17.5.1

vhost2,[~],12:32(0)$ host 172.17.5.1
Host 1.5.17.172.in-addr.arpa. not found: 3(NXDOMAIN)

Okay, and this also works from ops and boss:

ops,[~],12:43(0)$ host virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net
virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net is an alias for pcvm5-1.utah.geniracks.net.
pcvm5-1.utah.geniracks.net has address 172.17.5.1

ops,[~],12:43(0)$ host 172.17.5.1
Host 1.5.17.172.in-addr.arpa. not found: 3(NXDOMAIN)

boss,[~],12:44(0)$ host virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net
virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net is an alias for pcvm5-1.utah.geniracks.net.
pcvm5-1.utah.geniracks.net has address 172.17.5.1

boss,[~],12:44(0)$ host 172.17.5.1
Host 1.5.17.172.in-addr.arpa. not found: 3(NXDOMAIN)

This comment is too long: summarizing in a different comment.

[chaos@bbn.com]

Summary of the above: it seems reasonable that there's no real reason to resolve an address which can't be reached. However, i think if you are going to do forward lookups for the private addresses, you should do reverse lookups too.

[stoller@flux.utah.edu]

Just a heads up that reverse lookup for the 172 network now works!

[chaos@bbn.com]

Okay, so the last comment on this ticket was that forward and reverse lookups should work locally to the rack (e.g. from boss and ops and from VMs themselves). Well, let's check it out. On boss:

boss,[~],13:57(0)$ host virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net
virt1.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net is an alias for pcvm3-4.utah.geniracks.net.
pcvm3-4.utah.geniracks.net has address 172.17.3.4

boss,[~],13:57(0)$ host 172.17.3.4
4.3.17.172.in-addr.arpa domain name pointer pcvm3-4.utah.geniracks.net.

This looks good to me.