[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[LDM #BXQ-199970]: Re: LDM access to data feeds

Hi James,

re:
> I noticed you typed the wrong address for horus in your nslookup(
> horus.atmos.ucla.edu....not horus.atmosl.ucla.edu ).

Actually, my first 'nslookup' had the 'atmosl' instead of 'atmos',
but I corrected that in a second go.  The issue, however, is not
doing the forward lookup (name -> IP), but, rather, in doing the
reverse lookup.  I cut and pasted the IP address of the machine
that we are denying, 169.232.145.76, from the LDM log file on the
back end node of our relay cluster, idd.unidata.ucar.edu, that
is trying to field the REQUEST(s).  Here is a snippit from that
log file:

20170118T190239.783407Z ldmd[11756] NOTE ldmd.c:637:handle_connection() Denying 
connection from "169.232.145.76" because not allowed
20170118T190336.472998Z ldmd[11868] NOTE ldmd.c:637:handle_connection() Denying 
connection from "169.232.145.76" because not allowed
20170118T190336.727406Z ldmd[11869] NOTE ldmd.c:637:handle_connection() Denying 
connection from "169.232.145.76" because not allowed
20170118T190336.913841Z ldmd[11870] NOTE ldmd.c:637:handle_connection() Denying 
connection from "169.232.145.76" because not allowed

re:
> Anyway, horus did
> have a change of IP last summer (now 169.232.145.76 instead of
> 128.97.77.43). The server had been moved to a new building that didn't
> allow connections on the 77 subnet.

OK.  I was under the impression that your feed problems started
recently, not this past summer.  If this assumption is correct, it
would mean that the DNS problems for your machine are also recent.

re:
> By the way, I still got a similar result using telnet for
> 
> telnet idd.tamu.edu 388
> telnet iddb.unidata.ucar.edu 388

Both of these relay clusters have a blanket rule for '.edu' machines.
Your 'telnet' experience reaffirms that the problem is related to
reverse DNS.

For interest sake, I just logged onto a non-Unidata user machine to
see what their DNS shows for horus.  Here is what I got:

/home/ldm% nslookup horus.atmos.ucla.edu
Server:         131.156.116.210
Address:        131.156.116.210#53

Non-authoritative answer:
Name:   horus.atmos.ucla.edu
Address: 169.232.145.76

/home/ldm% nslookup 169.232.145.76
;; Got SERVFAIL reply from 8.8.8.8, trying next server
;; Got SERVFAIL reply from 131.156.116.210, trying next server
;; Got SERVFAIL reply from 131.156.116.210, trying next server
;; Got SERVFAIL reply from 131.156.1.11, trying next server
Server:         8.8.8.8
Address:        8.8.8.8#53

** server can't find 76.145.232.169.in-addr.arpa: SERVFAIL

Since this is exactly what we are seeing, it should indicate
that the problem is related to UCLA's DNS handling for your
machine.

Question:

- what do you get when running the 'nslookup' tests above?

  nslookup horus.atmos.ucla.edu
  nslookup 169.232.145.76

re:
> It times out almost immediately.

Unfortunately, I can't explain the 'telnet' results.

What does 'notifyme -vl- -f ANY -h idd.tamu.edu' return?

re:
> The odd thing is that horus can communicate with indra, out main server (indra
> will send data onto horus without complaint) even though their in separate 
> buildings.

When you say send data, do you mean by LDM transfers?  If yes, this is 
interesting
indeed as it should mean one of two things:

- the ALLOW on indra for horus is by IP address, not by fully qualified name

- reverse DNS for horus.atmos.ucla.edu exists locally

  This could happen, for instance, if the /etc/hosts file on indra has a
  hardcoded entry for horus and its IP.

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: BXQ-199970
Department: Support LDM
Priority: Normal
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.