This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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.