What does Net::HTTP use for name resolution?

I have the following in a controller method:

    begin       response = Net::HTTP.post_form(URI.parse(File.join(@site.url, 'scan_folder.json')), {inlay_key: @site.key})       @response = JSON.parse(response.body.to_s)['remote']       @response_type = 'success'       @site.tested_client = true       @site.save     rescue       @response = 'Could not locate Inlay Client.'       @response_type = 'error'     end

And it seems to work very well. But I have a test site that it is not finding. When I comment out the rescue portion, the error I get indicates that the host could not be found. I have tried adding a line to the hosts file (the way you would on a Mac to do fake DNS for a development site) and this too appears to be ignored completely. The Rails server is running on Ubuntu 14, with all the latest patches, and I even tried rebooting the entire server to get any caches to clear. Dig on the server is able to find the test machine, but Net::HTTP on the same server cannot.

Can anyone offer a direction to start looking? Are there configurations that I could be doing to ensure that lookup is exhaustive before giving up?

Thanks,

Walter

The (std) library name is Resolv, and no, it doesn't use /etc/hosts by default, just the servers referenced in /etc/resolv.conf.

There is however a Resolv::Hosts that you could fall back to for test purposes.

What's in the /etc/resolv.conf on your server?

And it seems to work very well. But I have a test site that it is not finding. When I comment out the rescue portion, the error I get indicates that the host could not be found. I have tried adding a line to the hosts file (the way you would on a Mac to do fake DNS for a development site) and this too appears to be ignored completely. The Rails server is running on Ubuntu 14, with all the latest patches, and I even tried rebooting the entire server to get any caches to clear. Dig on the server is able to find the test machine, but Net::HTTP on the same server cannot.

The (std) library name is Resolv, and no, it doesn't use /etc/hosts by default, just the servers referenced in /etc/resolv.conf.

There is however a Resolv::Hosts that you could fall back to for test purposes.

What's in the /etc/resolv.conf on your server?

Thanks for the tip. Here's the contents:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 8.8.4.4 nameserver 8.8.8.8 nameserver 209.244.0.3

I'm going to experiment with adding my EasyDNS hosts to this lookup list.

Walter

And it seems to work very well. But I have a test site that it is not finding. When I comment out the rescue portion, the error I get indicates that the host could not be found. I have tried adding a line to the hosts file (the way you would on a Mac to do fake DNS for a development site) and this too appears to be ignored completely. The Rails server is running on Ubuntu 14, with all the latest patches, and I even tried rebooting the entire server to get any caches to clear. Dig on the server is able to find the test machine, but Net::HTTP on the same server cannot.

The (std) library name is Resolv, and no, it doesn't use /etc/hosts by default, just the servers referenced in /etc/resolv.conf.

There is however a Resolv::Hosts that you could fall back to for test purposes.

What's in the /etc/resolv.conf on your server?

Thanks for the tip. Here's the contents:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 8.8.4.4 nameserver 8.8.8.8 nameserver 209.244.0.3

I'm going to experiment with adding my EasyDNS hosts to this lookup list.

I tried, but failed to get the resolv.conf file to update to include my EasyDNS name servers. But for some reason, fiddling with this, and trying out Resolv directly in a Ruby test script seemed to jar something loose, and the previously hidden host is now being found by the Net::HTTP command, and all is just working. I hate when that happens, I wish there was something I could learn from this and apply again in future.

Walter