hashicorp / terraform-provider-dns

Utility provider that supports DNS updates (RFC 2136) and can optionally be configured with secret key based transaction authentication (RFC 2845).
https://registry.terraform.io/providers/hashicorp/dns/latest
Mozilla Public License 2.0
112 stars 71 forks source link

Windows Server DNS - The message or signature supplied for verification has been altered #215

Open storkeyp opened 2 years ago

storkeyp commented 2 years ago

Terraform CLI and Provider Versions

Terraform v1.2.1 on windows_amd64

Terraform Configuration

provider "dns" {
    update {
      server                  = "${var.domain_controller}.${var.domain_name}"
      gssapi {
        realm                 = upper("${var.domain_name}")
        username              = var.username
        password              = var.password
      }
    }
}

resource "dns_a_record_set" "wyse" {
    zone = "${var.dns_cname}.${var.dns_zone}"
    addresses = [
        phpipam_address.wms_ip_address[0].ip_address
    ]
}

Expected Behavior

DNS A record added to zone, or modified if it already exists

Actual Behavior

A record is successfully created, but Terraform apply fails with the following error:

Error: Error updating DNS record: The message or signature supplied for verification has been altered

with module.vms.dns_a_record_set.wyse, on ..\modules\vms\wms.tf line 99, in resource "dns_a_record_set" "wyse": 99: resource "dns_a_record_set" "wyse" {

Steps to Reproduce

  1. terraform apply

How much impact is this issue causing?

Medium

Logs

No response

Additional Information

Windows Server 2012 R2 Standard, domain integrated zone

Code of Conduct

SpeedHighway commented 2 years ago

This one's occuring for us, as well, but we're using a cname and doing an edit, for an imported record. Unfortunately, the edit did NOT occur, in our case.

EDIT: For clarification, we're trying to add/edit entries to 3 different DNS servers, and getting this result on all 3.

EDIT2: Is it possible that the RR messages are being created incorrectly? I find it hard to believe it wouldn't have been noticed before now if this is a problem, but all of the test cases inside the dns project's repository use the phrases "IN A" or "IN CNAME", whereas, this project is setting them up as "A" or "CNAME", without the word "IN". I don't know if it makes a difference, but wonder if it could. https://github.com/miekg/dns/blob/40060b4a4b85b14867003343f64bfd5cd64ea256/duplicate_test.go

mtlucas commented 2 years ago

I had the same problem and fixed it by changing my DNS zone Properties to "Dynamic updates: Secure only". It was failing when I had "Nonsecure and Secure" selected.

EDIT: OK, this happened again even after changing to secure updates. Seems intermittent and still problematic.

RahmanBadru commented 1 year ago

Has anybody been able to solve this, i have the same issue and hence i cant destroy the records and achieve desired state

ranExl commented 1 year ago

Same here. Did anyone manage to pass this one?

Aiikon commented 1 year ago

Try making your DNS server name all lowercase if it's not.

I had the exact same issue. I finally tested on a RHEL server and got a similar sounding error mentioned in #213 and the fix was the same. Changing server to lowercase worked for both Windows and Linux.

ranExl commented 1 year ago

Getting a different error now - Error: Error updating DNS record: read udp _:65428->_:53: i/o timeout

Aiikon commented 1 year ago

I've found this error also occurs with AD/GSSAPI on the Windows when multiple records are being updated simultaneously. It seems somewhere in the pipeline the DNS module is not thread safe. I've been able to work around the issue forcing a single thread using "terraform apply -parallelism 1" but this is only usable if DNS resources aren't paired with resources that take a long time to provision like VMs. I haven't had a chance to test if parallelism is a problem or not on Linux. I wish there was a configuration to control the thread count per-resource or provider to make this easier.

jayo86 commented 1 year ago

Try making your DNS server name all lowercase if it's not.

I had the exact same issue. I finally tested on a RHEL server and got a similar sounding error mentioned in #213 and the fix was the same. Changing server to lowercase worked for both Windows and Linux.

fyi this fixed it for me

cbus-guy commented 1 year ago

We have the same issue. Don't know why this isn't getting any traction. ???

bendbennett commented 5 months ago

Hi @storkeyp 👋

Sorry you ran into trouble here. Can I confirm the following:

If the issue persists, then it would be very helpful if you could gather the details necessary to reproduce this issue in a local development environment. Thanks.