Forcing a Deployment Server to Not Attempt to Resolve IP Address

[jchensor]

Hello, everyone.

When it comes to Indexers, there is an option you can use in "inputs.conf" where you add the following line to your "splunktcp" stanza:

connection_host=ip

What this will do is that, when the Indexer receives an event from a Forwarder, it will not try to resolve the IP Address of the Forwarder into its DNS name. I've had several timeout issues and broken pipes caused by this attempt to resolve the DNS name. So adding the setting above fixes the problem.

However, I believe the same thing is happening on my Deployment Server. When forwarders connect to my Deployment Server to look for new settings, the Deployment Server locks up, particularly with public subnets, because I believe it is trying to resolve all of the IP Addresses.

So the question is: Is there an equivalent setting or does anyone know of a way that I can configure the Deployment Server to NOT try and resolve the IP Addresses of all of the Forwarders that contact it to look for new settings?

Any ability to do such a thing would be greatly appreciated. Thanks, everyone!

EDIT: I should also add that my Deployment Server is on a Unix-based platform, so even if there's some configuration I can do to the machine's network settings, I'd be happy with that.

• James

[dwaddle]

I don't think there is such an option. Classifying hosts by name is one of the most crucial functions of Splunk Deployment Server. I wouldn't expect name resolution to wedge up a Deployment server - unless you're saying you have many clients connecting that don't have valid reverse DNS.

What I might suggest is running a local caching DNS server on your deployment server host. Then you'll at least get a quick answer that reverse DNS could not resolve. BIND can do this pretty easily, but for many practical purposes, dnsmasq is just as good.