Terraform failure. DNS?

[MuhammadAlkarouri]

Terraform Version

Terraform v0.9.5

Affected Resource(s)

Unable to run terraform plan. Probably core.

Terraform Configuration Files

# Configure the Microsoft Azure Provider
provider "azurerm" {
    subscription_id = "<private value here>"
    client_id = "<private value here>"
    client_secret = "<private value here>"
    tenant_id = "<private value here>"
}

# Create a resource group
resource "azurerm_resource_group" "playground" {
  name     = "PlayGroup"
  location = "UK West"
}

Debug Output

The issue seems to be a DNS timeout. The machine used is MacOS 10.12.5

10.70.2.1:53: read udp 10.70.2.45:57869->10.70.2.1:53: i/o timeout

The full output is at https://gist.github.com/MuhammadAlkarouri/26144f59129e6c46b29d59b89c04374a

The machine is able to use DNS normally otherwise. For example, trying to curl https://login.microsoftonline.com succeeds in connecting to it.

Expected Behavior

What should have happened?

A plan produced.

Actual Behavior

What actually happened?

Error: unable to list provider registration status. i/o timeout.

Steps to Reproduce

1. terraform plan

[jbardin]

Hi @MuhammadAlkarouri,

Yes, this appears to be a DNS issue. Do you have any custom name resolution settings on your host, possible in /etc/resolv.conf or /etc/resolver?

Can you query the server at 10.70.2.1 to resolve login.microsoftonline.com?

[MuhammadAlkarouri]

/etc/resolv.conf has 10.70.2.1 as the only entry.

I have a /etc/resolver/vagrant.test which points to a nameserver at 127.0.0.1:10053. The configuration was generated by the landrush vagrant plugin.

The server 10.70.2.1 resolves login.microsoftonline.com every time.

Just to add to the story:

I created a virtual machine (CentOS Linux) inside my machine and tried terraform from there. Same problem. I then installed a caching dns server in the virtual machine (bind) and configured the virtual machine to use it. Since then, terraform is working successfully inside the virtual machine (plan, apply, show, and for any number of times).

[jbardin]

Thanks for the extra info.

It's not clear what's happening exactly, since Go is using 10.70.2.1, but is getting a timeout.

It may have something to do with the Go resolver not supporting the MacOS /etc/resolver directories, but I don't think that explains the VM behavior since that would only need to use whatever config is provided on the Linux host.

I'll see if I can recreate anything here, but let us know if you come up with any other information.

[bclodius]

@MuhammadAlkarouri are you using a Corporate VPN? I've faced similar issues with DNS on MAC while connected to a VPN and using terraform in the past. Based on your response I may be able to help with remediation steps.

[MuhammadAlkarouri]

No VPN involved. Connected directly to the corporate network.

[soufi]

Hi,

I don't know if this issue was resolved, but I have the same error and i'm using PiHole as my private DNS. I'm running MacOS Big Sur and Terraform v1.0.1

Here's the error:

dial tcp: lookup anypoint.mulesoft.com on 192.168.0.254:53: read udp 192.168.0.51:0->192.168.0.254:53: i/o
│ timeout

My workaround now is to run nslookup anypoint.mulesoft.com then run the terraform command, and it works.

any thoughts ?

---

EDIT

Since i'm using pihole as DNS, I suspect that it might be taking too much time to perform its magic.

Here's a link on how to optimize pihole HTTPS using iptable rules.

[erdebee]

For anyone trying to get this to work for their VPN DNS that uses selective DNS (e.a. only use the VPN DNS for specific internal domains) This forces your MAC to use mDNS. Sadly GO applications are compiled using an old DNS stack that doesnt support this. To fix this, follow the steps as described here: https://github.com/greenboxal/dns-heaven

[apparentlymart]

Hi all,

It seems like this issue got a bit stuck where we weren't sure whether it was a Terraform problem or a local network problem. Unfortunately this sort of problem does tend to end up in that state, because we have no way to debug someone's local network stack and understand how its behavior might be affecting Terraform and whether Terraform could be doing something differently to avoid that.

However, one positive thing I can say is that some of the comments above were discussing how Terraform at the time was not able to properly integrate with the macOS resolver, which was true but has been addressed in modern Terraform. We now build darwin_amd64 release packages on a macOS system using the standard macOS toolchain and so Terraform is linked to the C library and thus the correct DNS resolver. That might not yet be true for all providers, since they are separate programs built separately, but is true for requests that Terraform CLI makes itself, which includes requests from backends and requests to install modules and providers.

(Note that this original request was about a provider, so I can't say for certain whether modern versions of that particular provider are linked with the macOS resolver. Like all providers, the Azure provider now has its own separate repository and so that would typically be a better place to raise any concerns about the provider's own behavior.

I'm going to close this just because this was long enough ago that I don't expect we'll be able to do anything specific to address it. If you have network-related problems when using Terraform, I suggest starting a topic in the community forum, since that's often a better place for unstructured Q&A and debugging, whereas we try to use GitHub issues only for specific problems that have a clear path to being resolved.

Thanks for raising this, and sorry it sat here without attention for so long.

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.