Terraform DNS provider dns_ptr_record connection refused

Terraform Providers
1

Hi,

I have a previously working terraform pipeline that creates Vsphere VM resources and the associated DNS records for them that has suddenly started to misbehave:

Terraform version 1.2.4, DNS provider version 3.3.0

Error: Error updating DNS record:

with dns_ptr_record.k8s_master_reverse[1],

on k8s-master_dns.tf line 12, in resource "dns_ptr_record" "k8s_master_reverse":

12: resource "dns_ptr_record" "k8s_master_reverse" {

read udp 127.0.0.1:52786->127.0.0.1:53: read: connection refused

Provider:

provider "dns" {
  update {
    server = "192.168.0.1"
    key_name = "nsadmin."
    key_algorithm = "hmac-md5"
    key_secret = var.dns_key_secret
  }
}

I don’t know why it is trying to connect to 127.0.0.1:53 when the provider is configured to point to 192.168.0.1. The forward zone resources all deploy fine.

These pipelines are deployed using gitlab with docker based tooling launched by docker-machine on the gitlab runner.

2

Hi,

I just wanted to chime in and say that I am having the same issue, but with CNAME records instead of PTR records. Creating A records work perfectly, but CNAME records can not be created, with the following error:

Error: Error updating DNS record:

  with dns_cname_record.control-plane["0"],
  on main.tf line 221, in resource "dns_cname_record" "control-plane":
 221: resource "dns_cname_record" "control-plane" {

read udp 127.0.0.1:55947->127.0.0.1:53: read: connection refused

Provider:

provider "dns" {
  update {
    server        = "dns01.lab.gbg.wahlberger.lan"
    key_name      = "nsupdate.k8s.gbg.wahlberger.lan."
    key_algorithm = "hmac-sha512"
    key_secret    = "<secret key>"
  }
}

Resource:

locals {
  datetime = formatdate("YYYYMMDDhhmmss", timestamp())

  controllers_def = {
    name  = "kube-controller",
    count = 3
  }

  controllers = flatten([
    for i in range(1, local.controllers_def.count + 1) : {
      index    = i - 1
      hostname = format("%s%02d-%s", local.controllers_def.name, i, local.datetime)
    }
  ])
}

...

resource "dns_cname_record" "control-plane" {
  for_each = { for c in local.controllers : c.index => c.hostname }
  zone     = "lab.gbg.wahlberger.lan."
  name     = format("kubectl%02d", each.key + 1)
  cname    = format("%s.lab.gbg.wahlberger.lan.", each.value)
  ttl      = 5
}

Running Terraform version 1.4.5, DNS provider version 3.3.0, on Mac OS Ventura 13.3.1.

3

Are you also running terraform on a container? What I don’t understand is that I haven’t changed anything at all in the CI script, the terraform container, the versions, yet it has gone from working to not working.

4

I am not using a container. I am running terraform on bare metal on a Macbook Pro. I am however running the same dns provider version as you are, version 3.3.0. I see that a new version of the provider was just released (3.3.1) that fixes our exact issue:

Release v3.3.1 · hashicorp/terraform-provider-dns (github.com)

Terraform configuration values not being used to set the DNSClient · Issue #290 · hashicorp/terraform-provider-dns (github.com)

You say that you haven’t changed anything in the CI script, yet it seems that you are using a very recent version of the dns provider (3.3.0) which was released 2 days ago. I assume that you are doing something like the following:

    dns = {
      source  = "hashicorp/dns"
      version >= "3.0.0"
    }

which downloads the latest available version of the provider, yes?

Either way, using the latest 3.3.1 version of the dns provider fixes my issue, and hopefully it will fix yours as well! Give it a go and let me know how it goes :grinning:

1 Like
5

Yeah that fixed it for me too. Here is what I think must have happened:

3.3.0 was released a few days ago and since I didn’t specify a version of the provider it used the latest thus picking up the bug.

Lesson learned, always specify a known-good version! :slight_smile:

Thanks Erik

1 Like
6

To prevent this sort of problem, you can add the .terraform.lock.hcl file generated by terraform init to your version control system. That file is how Terraform remembers between runs which version of each provider was selected, and is there to help with this exact problem of ensuring that the behavior of your configuration should not change without committing new changes to your version control system, even if new provider versions appear in the meantime.

(You can still use terraform init -upgrade to explicitly upgrade to the latest versions. This just means that the upgrades happen at a time that’s convenient to you, not just whenever the provider developer publishes something new, and you can communicate about the upgrade via the same code review processes you follow for other code changes.)

1 Like