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

[LDM #RVC-520134]: Reverse DNS Lookup Oddity

Bob,

Interesting!

The 28 second timeout definitely indicates a DNS resolution issue.

Offhand, I can't think of any reason why the LDM wouldn't resolve an IP address 
into a hostname while nslookup(1) and dig(1) would. I'll ask around.

The LDM uses the obsolete and thread-unsafe system-call `gethostbyaddr(3)`, but 
does so safely -- so there shouldn't be any problem.

The glibc man-page on `gethostbyaddr` has this:

       The domain name queries carried out by gethostbyname() and 
gethostbyaddr() use a combination of any or all of the name server named(8), a 
broken out line from /etc/hosts, and the Network Information Service  (NIS
       or YP), depending upon the contents of the order line in /etc/host.conf. 
 The default action is to query named(8), followed by /etc/hosts.

So you might check your named(8) installation and the file "/etc/host.conf".

I suspect that dig(1) and nslookup(1) use getnameinfo(3) instead of 
gethostbyaddr(3) and that getnameinfo(3) uses a different sequence of 
resolution events.

I'll see about replacing gethostbyaddr(3).

> We have a situation where an upstream LDM server ALLOWS by matching
> the fully-qualified host name of any downstream LDM server.  After a
> downstream server was patched today and rebooted, it came back up and the
> upstream server refused to allow it to connect, citing an unresolvable
> hostname:
> 
> Upstream LDM log...
> 20180126T190606.500190Z ldmd[12972] WARN error.c:236:err_log() Couldn't 
> resolve "10.100.152.173" to a hostname in 28.0296 seconds
> 20180126T190606.500275Z ldmd[12972] NOTE ldmd.c:632:handle_connection() 
> Denying connection from "10.100.152.173" because not allowed
> 20180126T190606.500388Z ldmd[12972] NOTE ldmd.c:185:cleanup() Exiting
> 20180126T190606.500950Z ldmd[19465] NOTE ldmd.c:168:reap() child 12972 exited 
> with status 1
> 
> Downstream LDM log...
> 20180126T210033.553866Z 10.100.152.131[9003] NOTE error.c:236:err_log() 
> Upstream LDM didn't reply to FEEDME request; RPC: Unable to receive; errno = 
> Connection reset by peer
> 20180126T210133.554065Z 10.100.152.131[9003] NOTE requester6.c:588:req6_new() 
> LDM-6 desired product-class: 20180126200133.554013 TS_ENDT {{EXP, 
> "^WXDESK"},{NONE, "SIG=f19ec5266bcbf29bfcfc6a0cbe5ea2f8"}}
> 
> That sounds like a simple DNS issue, however both nslookup and dig
> executed on the ALLOWING server both return the proper fully-qualified
> hostname.
> 
> nslookup 10.100.152.173
> Server:         10.100.100.21
> Address:        10.100.100.21#53
> 
> 173.152.100.10.in-addr.arpa     name = (fully qualified hostname).
> 
> We could have solved the problem in a number of ways, first by explicitly
> allowing the IP address in the ldmd.conf file, or by adding the DNS entry
> to /etc/hosts.  We did the latter to avoid restarting the upstream LDM
> and the problem was immediately resolved.
> 
> My question to you is whether or not you can think of a reason that an
> upstream LDM server (that can successfully perform a reverse-DNS lookup)
> would fail to allow a FEEDME request? By what method does LDM perform
> a reverse-DNS lookup?  All servers in question are running CENTOS 6.8
> (upstream) / 6.9 (downstream) and LDM v6.13.0 (both).

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: RVC-520134
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.