Cannot connect to registry.terraform.io

[andreaugustoaragao]

Using a very simple script that is failing during initialization (downloading provider packages).

What caught my attention in the logs was this: Get │ "https://registry.terraform.io/.well-known/terraform.json": dial tcp: lookup registry.terraform.io on [::1]:53:

I tested DNS resolution and all is working perfectly fine. I tested and I can reach registry.terraform.io url using curl (https://registry.terraform.io/.well-known/terraform.json).

The full output with logs is below:

~/src/devops/k8s/terraform  
❯  TF_LOG=TRACE terraform init
2022-06-02T23:08:16.334-0600 [INFO]  Terraform version: 1.2.2
2022-06-02T23:08:16.334-0600 [DEBUG] using github.com/hashicorp/go-tfe v1.0.0
2022-06-02T23:08:16.335-0600 [DEBUG] using github.com/hashicorp/hcl/v2 v2.12.0
2022-06-02T23:08:16.335-0600 [DEBUG] using github.com/hashicorp/terraform-config-inspect v0.0.0-20210209133302-4fd17a0faac2
2022-06-02T23:08:16.335-0600 [DEBUG] using github.com/hashicorp/terraform-svchost v0.0.0-20200729002733-f050f53b9734
2022-06-02T23:08:16.335-0600 [DEBUG] using github.com/zclconf/go-cty v1.10.0
2022-06-02T23:08:16.335-0600 [INFO]  Go runtime version: go1.18.1
2022-06-02T23:08:16.335-0600 [INFO]  CLI args: []string{"/home/andre/.asdf/installs/terraform/1.2.2/bin/terraform", "init"}
2022-06-02T23:08:16.335-0600 [TRACE] Stdout is a terminal of width 178
2022-06-02T23:08:16.335-0600 [TRACE] Stderr is a terminal of width 178
2022-06-02T23:08:16.335-0600 [TRACE] Stdin is a terminal
2022-06-02T23:08:16.335-0600 [DEBUG] Attempting to open CLI config file: /home/andre/.terraformrc
2022-06-02T23:08:16.335-0600 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2022-06-02T23:08:16.335-0600 [DEBUG] ignoring non-existing provider search directory terraform.d/plugins
2022-06-02T23:08:16.335-0600 [DEBUG] ignoring non-existing provider search directory /home/andre/.terraform.d/plugins
2022-06-02T23:08:16.335-0600 [DEBUG] ignoring non-existing provider search directory /home/andre/.local/share/terraform/plugins
2022-06-02T23:08:16.335-0600 [DEBUG] ignoring non-existing provider search directory /usr/local/share/terraform/plugins
2022-06-02T23:08:16.335-0600 [DEBUG] ignoring non-existing provider search directory /usr/share/terraform/plugins
2022-06-02T23:08:16.335-0600 [INFO]  CLI command args: []string{"init"}

Initializing the backend...
2022-06-02T23:08:16.336-0600 [TRACE] Meta.Backend: no config given or present on disk, so returning nil config
2022-06-02T23:08:16.336-0600 [TRACE] Meta.Backend: backend has not previously been initialized in this working directory
2022-06-02T23:08:16.336-0600 [DEBUG] New state was assigned lineage "f3186336-8a0a-e973-b442-a3f9d9dfdd6e"
2022-06-02T23:08:16.336-0600 [TRACE] Meta.Backend: using default local state only (no backend configuration, and no existing initialized backend)
2022-06-02T23:08:16.336-0600 [TRACE] Meta.Backend: instantiated backend of type <nil>
2022-06-02T23:08:16.336-0600 [DEBUG] checking for provisioner in "."
2022-06-02T23:08:16.336-0600 [DEBUG] checking for provisioner in "/home/andre/.asdf/installs/terraform/1.2.2/bin"
2022-06-02T23:08:16.336-0600 [TRACE] Meta.Backend: backend <nil> does not support operations, so wrapping it in a local backend
2022-06-02T23:08:16.336-0600 [TRACE] backend/local: state manager for workspace "default" will:
 - read initial snapshot from terraform.tfstate
 - write new snapshots to terraform.tfstate
 - create any backup at terraform.tfstate.backup
2022-06-02T23:08:16.336-0600 [TRACE] statemgr.Filesystem: reading initial snapshot from terraform.tfstate
2022-06-02T23:08:16.336-0600 [TRACE] statemgr.Filesystem: snapshot file has nil snapshot, but that's okay
2022-06-02T23:08:16.336-0600 [TRACE] statemgr.Filesystem: read nil snapshot

Initializing provider plugins...
- Finding kreuzwerker/docker versions matching "~> 2.13.0"...
2022-06-02T23:08:16.336-0600 [DEBUG] Service discovery for registry.terraform.io at https://registry.terraform.io/.well-known/terraform.json
2022-06-02T23:08:16.336-0600 [TRACE] HTTP client GET request to https://registry.terraform.io/.well-known/terraform.json
2022-06-02T23:08:16.336-0600 [ERROR] Checkpoint error: Get "https://checkpoint-api.hashicorp.com/v1/check/terraform?arch=amd64&os=linux&signature=349d3892-72e9-e1ee-ed38-878b9061dbbf&version=1.2.2": dial tcp: lookup checkpoint-api.hashicorp.com on [::1]:53: read udp [::1]:55244->[::1]:53: read: connection refused
- Finding latest version of hashicorp/libvirt...
2022-06-02T23:08:16.337-0600 [DEBUG] Service discovery for registry.terraform.io at https://registry.terraform.io/.well-known/terraform.json
2022-06-02T23:08:16.337-0600 [TRACE] HTTP client GET request to https://registry.terraform.io/.well-known/terraform.json
╷
│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider kreuzwerker/docker: could not connect to registry.terraform.io: Failed to request discovery document: Get
│ "https://registry.terraform.io/.well-known/terraform.json": dial tcp: lookup registry.terraform.io on [::1]:53: read udp [::1]:36006->[::1]:53: read: connection refused
╵

╷
│ Error: Failed to query available provider packages
│
│ Could not retrieve the list of available versions for provider hashicorp/libvirt: could not connect to registry.terraform.io: Failed to request discovery document: Get
│ "https://registry.terraform.io/.well-known/terraform.json": dial tcp: lookup registry.terraform.io on [::1]:53: read udp [::1]:38296->[::1]:53: read: connection refused
╵`

[apparentlymart]

Hi @andreaugustoaragao! Sorry this isn't working, and thanks for reporting it.

From the messaging here it seems that Terraform has concluded that it should make DNS requests by connecting to a nameserver running on localhost.

I think an important detail to determine here is: should Terraform be resolving DNS using a DNS server on localhost? Or to ask the question another way: is the problem here what Terraform is using the wrong nameserver, or is this the correct nameserver to use but for some reason Terraform is failing to connect to it even though your other software can connect to it okay?

This distinction is important because it will help understand if the problem is in the detection of the resolver configuration or if this is some other problem with the actual DNS client after it has already determined the correct DNS server address.

If you can share it without betraying any sensitive data, it may be helpful to share the contents of your system's /etc/resolv.conf and /etc/nsswitch.conf files.

Thanks again!

[andreaugustoaragao]

Thank you for your reply. It sent me in the right direction. All is working now!

For reference, I'm using arch linux with systemd-resolved.

The solution to the problem can be found here:

Reference:

https://wiki.archlinux.org/title/Systemd-resolved#DNS

[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.