Add support for looking up Private DNS Name for hostname

[mihado]

In some circumstances - for example proxy settings that are configurable on hostnames - the private_dns_name is preferred over the private_ip_address

When private_dns is provided as the option in .kitchen.yml, the value of private_dns_name will be returned

driver:
  interface: private_dns

When this option is unset, the private_ip_address will be returned as in the current implementation

[mihado]

\cc @zl4bv @tjnicholas

[jkeiser]

@MEKF is the private dns name ever preferred over the private ip? Do we want to inject this third in the priority instead of fourth?

[zl4bv]

is the private dns name ever preferred over the private ip?

Given a user is behind a proxy
And the user's no_proxy list is set to .compute.internal (because IP prefixes are not supported)
And the kitchen-ec2 instance is also behind the proxy
And the transport is set to WinRM

When kitchen-ec2 connects to the instance

Then it should connect to the instance using the private DNS address
And the WinRM requests should not go through the proxy

[jkeiser]

I'm unclear whether that is a more common or less common case than the opposite. Well, 👍 at any rate, seems reasonable.

[zl4bv]

The flipside is that the compute.internal. zone is generally only resolvable inside AWS. So a host outside of AWS would not be able connect to a test instance using private DNS even if the correct connectivity/routing was in place.

Certainly not sure which case is more common, but the "play it safe" option in my opinion would be to keep the current order with private IP address preferred over private DNS.

[jkeiser]

Fair enough! Paging @test-kitchen/maintainers @test-kitchen/kitchen-ec2-maintainers

[proffalken]

Code looks fine to me, approve of the ordering as well - I've had some real issues with Ansible when trying to SSH via private_dns so defaulting to the IP is the sensible thing to do IMHO.

+1

[mihado]

thanks @jkeiser @zl4bv