-
Notifications
You must be signed in to change notification settings - Fork 75
Description
Terraform CLI and Provider Versions
Terraform v1.4.5
on linux_amd64
- provider registry.terraform.io/hashicorp/dns v3.3.1
Terraform Configuration
terraform {
required_providers {
dns = {
source = "hashicorp/dns"
version = "3.3.1"
}
}
}
# Configure the DNS Provider
provider "dns" {
update {
# Using the hostname is important in order for an SPN to match
server = "n1.example.com"
gssapi {
realm = "EXAMPLE.COM"
username = "dns_admin"
password = "secr3t!"
}
}
}
# Create a DNS A record set
resource "dns_cname_record" "alias" {
zone = "subdomain.example.com." # This breaks, as the zone is 'example.com.'
# domain = "subdomain.example.com." # This is the subdomain where the alias is needed
name = "alias"
cname = "server.subdomain.example.com."
ttl = 300
# ...
}Expected Behavior
We have a single zone, example.com that has sub domains for different subnets, such as management, or t1, t2, etc. We also use generic names for hosts being built, lnx0002.app.example.com, and then provide a friendly, meaningful name based on the server role daffy.app.example.com.
Currently we achieve this by using nsupdate, but I have been unable to achieve a similar result with the terraform-dns-provider.
Using nsupdate -g, e.g:
[root@host terraform-dns-example]# kinit dns_admin
Password for [email protected]:
[root@host terraform-dns-example]# nsupdate -g
> zone example.com.
> update add alias.subdomain.example.com 300 CNAME server.subdomain.example.com
> send
>
> quit
[root@host terraform-dns-example]# nslookup alias.subdomain.example.com
Server: 1.2.3.4
Address: 1.2.3.4#53
alias.subdomain.example.com canonical name = server.subdomain.example.com.
Name: alias.subdomain.example.com
Address: 1.2.3.60Other attempts:
- Changing the zone to be
example.com, allows the code to work, however the alias is in the incorrect domain. - Changing the name to be alias.subdomain.example.com and the zone to be example.com, resulted in alias.subdomain.example.com.subdomain.example.com
- Changing the resource name to be
alias.subdomain.example.com, resulted in a validation error.
IMO, the name of the record should actually be the name argument appended with the domain argument, with the domain argument defaulting to the zone argument if not provided. The domain argument could include additional validation that it is a subdomain of the zone, to ensure that the DNS update request is logically correct.
Actual Behavior
[root@host terraform-dns-example]# terraform apply -auto-approve
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# dns_cname_record.cname will be created
+ resource "dns_cname_record" "alias" {
+ cname = "server.subdomain.example.com."
+ id = (known after apply)
+ name = "alias"
+ ttl = 300
+ zone = "subdomain.example.com."
}
Plan: 1 to add, 0 to change, 0 to destroy.
dns_cname_record.cname: Creating...
╷
│ Error: Error updating DNS record:
│
│ with dns_cname_record.cname,
│ on dns.tf line 16, in resource "dns_cname_record" "alias":
│ 16: resource "dns_cname_record" "alias" {
│
│ dns: bad authenticationSteps to Reproduce
terraform initterraform apply
How much impact is this issue causing?
High
Logs
No response
Additional Information
No response
Code of Conduct
- I agree to follow this project's Code of Conduct