Vagrant + VirtualBox: DNS resolution guarantees and TLS trust boundaries for HTTPS box downloads

Direct answers

1. Guest DNS guarantee

Vagrant does not document a minimum guarantee for guest DNS resolution across supported providers. Resolution is explicitly provider-dependent: the VirtualBox network mode, the guest OS resolver, DHCP-supplied DNS settings, and any host-resolver customizations determine the outcome. Vagrant orchestrates VM creation but does not standardize the guest name-resolution stack.

2. Surfacing DNS vs. TLS failure causes

There is no supported Vagrant flag that labels a vagrant box add failure as DNS versus TLS without enabling full debug output. The supported path is to read the error class and reproduce the request with host tools such as curl -v or openssl s_client using the same proxy environment.

3. Portable VirtualBox NAT DNS configuration

A Vagrantfile cannot portably configure VirtualBox NAT DNS proxy and host-resolver settings across providers. You can apply provider-specific customize calls, but they are VirtualBox-only, version-sensitive, and usually require vagrant reload.

Trust boundaries and proxy interactions

Box downloads are a host-side trust boundary. vagrant box add validates the download certificate against the Ruby/OpenSSL trust store of the Vagrant process, not the guest. A private CA must be trusted on the host, for example via --cacert or --capath if your installed Vagrant version supports them. Guest provisioner HTTPS calls are a separate boundary: trusting a CA on the host does not make the guest OS or provisioner trust it.

With an intercepting proxy, the client may never resolve the origin hostname itself because the proxy performs DNS for CONNECT. Resolver errors and TLS trust errors can therefore have different causes depending on whether a proxy is used and whether it re-signs certificates. Capturing HTTPS_PROXY and NO_PROXY is essential before changing resolver or trust settings.

Verification and scoped commands

Confirm the flags available in your installed versions before relying on them:

vagrant box add --help
VBoxManage modifyvm --help

Reproduce the download failure outside Vagrant using the same proxy environment:

curl -v https://example.com/path/to/box.box

A resolver error before CONNECT indicates DNS; certificate verify failed indicates host trust-store or TLS verification.

Inside the guest, test resolution and TLS separately:

getent hosts example.com
curl -v https://example.com/

If you apply VirtualBox DNS customizations in the Vagrantfile, run vagrant reload and compare guest resolution with host resolution for the same endpoint. Example customization (verify exact flag names with your VirtualBox version):

config.vm.provider "virtualbox" do |vb|
  vb.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
  vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
end

Do not use --insecure as a fix; it disables certificate verification and can hide a private-CA or proxy MITM problem.

Missing diagnostic detail

Are HTTPS_PROXY or NO_PROXY set in the environment where vagrant box add runs? The answer determines whether the failure is local DNS, proxy-side DNS, or host TLS trust.