[IDD #NRL-751259]: Joining IDD

Hi,

re: As soon as forward and reverse DNS are established for these machines
> > (at Boise State) and assuming that the IP addresses resolve to the
> > '.edu' namespace, either both of these machines will be able to REQUEST
> > feeds from the top level IDD relays at Unidata/UCAR, Penn State and
> > at UW/AOS.

> Reverse DNS is already set up on both of the machines.

I just tested to see if there is reverse DNS (IP -> name) for
each of the machines you listed, and the IP addresses are not being
resolved to fully qualified names.  Here is the output from the
two 'nslookup' invocations that I ran on a randomly picked real-server
backend for the idd.unidata.ucar.edu IDD top level relay cluster:

~: nslookup 132.178.231.143
Server:         208.67.222.222
Address:        208.67.222.222#53

** server can't find 143.231.178.132.in-addr.arpa.: NXDOMAIN

~: nslookup 132.178.231.144
Server:         208.67.222.222
Address:        208.67.222.222#53

** server can't find 144.231.178.132.in-addr.arpa.: NXDOMAIN

So, if reverse DNS has been setup at Boise State, it has not
been propagated to Internet domain name servers.

Also, forward DNS also does not exist for your machines:

~: nslookup Borah-ldm001.boisestate.edu
Server:         208.67.222.222
Address:        208.67.222.222#53

** server can't find Borah-ldm001.boisestate.edu: NXDOMAIN

~: nslookup Borah-ldm002.boisestate.edu
Server:         208.67.222.222
Address:        208.67.222.222#53

** server can't find Borah-ldm002.boisestate.edu: NXDOMAIN

re: I assume that the IP should be 132.178.231.144, not
132.q78.231.144, correct?

> Correct 132.178.231.144

Very good.

re:
> Forward and reverse DNS is set up for these machines. 

The 'nslookup' attempts show that this is not the case.

re:
> We have an HA
> environment so that if one node ever fails, we have a backup in its place.
> We set up a virtual address, 132.178.231.142 (which points to whichever the
> active node is) - but we are finding that even if you login to
> borah-ldm.boisestate.edu (132.178.231.142) it still show the backend node
> your physically accessing.

There is reverse DNS for 132.178.231.142:

~: nslookup 132.178.231.142
Server:         208.67.222.222
Address:        208.67.222.222#53

Non-authoritative answer:
142.231.178.132.in-addr.arpa    name = borah-ldm.boisestate.edu.

Authoritative answers can be found from:

If the IP address of the machine that is running the LDM is 132.178.231.142,
then the feed REQUEST(s) to the IDD relays that we, Penn State and UW/AOS
operate will be honored.  If, on the other hand, the IP address is either
132.178.231.143 or 132.178.231.144, the REQUEST(s) will not be honored
as reverse DNS is not available for these IP addresses, and our blanket
rule is for machines with names in the '.edu' domain.

re:
> This is a bright cluster and I am working with bright on a solution, but in
> the meantime, this allows us to access IDD using the physical address of
> the active node.

OK.

re:
> Hopefully, we can resolve this quickly. Thank you for all your assistance.

No worries.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: NRL-751259
Department: Support IDD
Priority: Critical
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.