Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

provider DNS failure on macOS on VPN #283

Open
rjhornsby opened this issue Sep 3, 2021 · 1 comment
Open

provider DNS failure on macOS on VPN #283

rjhornsby opened this issue Sep 3, 2021 · 1 comment

Comments

@rjhornsby
Copy link

This is similar, if not identical, to hashicorp/terraform-provider-kubernetes#969. More discussion about the underlying GOLANG issue as it relates to Terraform core hashicorp/terraform#3536

In summary, when connected to a VPN on a Mac, the consul provider is bypassing the local resolver configuration, and fails DNS lookups like consul.service.consul. This is a pending issue with Vault, and was previously an issue in Terraform core, but has since been fixed. We know Terraform is fixed because Terraform is able to handle a backend configured to use consul.service.consul, and the problem described here only happens when using the consul provider.

Terraform Version

Terraform v1.0.5 on macOS 11.5.2
consul provider 2.13.0

Affected Resource(s)

Affects the provider generally, but not terraform itself.

Terraform Configuration Files

terraform {

  required_version = ">= 1.0"

  backend "consul" {
    address = "consul.service.consul:8500"
    path    = "tfdocs/dns-testing/state"
  }

  required_providers {
    consul = {
      version = ">= 2.13.0"
    }
}

provider "consul" {
  address = "consul.service.consul:8500"
}

data "consul_keys" "client_config" {
  key {
    name = "config"
    path = "some/path"
  }
}

Expected Behavior

The provider should be able to resolve the name consul.service.consul

Actual Behavior

DNS lookup fails, but only for the provider.

│ Error: Failed to read Consul key 'some/path': Get "http://consul.service.consul:8500/v1/kv/some/path": dial tcp: lookup consul.service.consul on 192.168.3.7:53: no such host

Here, 192.168.3.7 is the local DNS server, not the DNS configured for and on the other side of the VPN tunnel. The OS configuration scutil --dns shows correct:

DNS configuration (for scoped queries)

resolver #1
  search domain[0] : ktzr.local
  nameserver[0] : 192.168.3.7
  if_index : 4 (en0)
  flags    : Scoped, Request A records
  reach    : 0x00020002 (Reachable,Directly Reachable Address)

resolver #2
  search domain[0] : mycorp01.com
  search domain[1] : node.consul
  search domain[2] : service.consul
  search domain[3] : mycorp02.com
  nameserver[0] : 10.10.0.4
  nameserver[1] : 10.10.0.5
  nameserver[2] : 10.11.0.5
  if_index : 13 (utun10)
  flags    : Scoped, Request A records
  reach    : 0x00000002 (Reachable)

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. terraform plan

Important Factoids

If I recompile the provider locally (no changes necessary), it seems to work fine. At least in this case, setting CGO_ENABLED to 0 or 1 in GNUMakefile, or leaving it out and compiling the code as is, doesn't change anything. Just recompiling seems to somehow fix it.

References

@remilapeyre
Copy link
Collaborator

Hi @rjhornsby, thanks for bringing this issue to my attention. I checked with the rest of the team and the release team is currently into this. I will notice you when we fix this :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants