What is the business impact you are facing?
Hi , We have domains say mildev.com and it has it original 4 NS assigned while creation. I want to append a few more name servers to it (my secondary NS).
but when i try to update the NS list using terraform it fails with
Error: Error creating ResourceDnsRecordSet: googleapi: Error 409: The resource 'entity.rrset' named 'mildev.com. (NS)' already exists, alreadyExists
Of-course, the name mildev.com NS [[NS_list_origina_]] is there but is there a way i can update? I see update is allowed using UI but why isnt it allowed via APIs?
Any guidance will be helpfull.
Thanks
type = string
default = "mildev.com."
}
resource "google_dns_managed_zone" "selected" {
name = format("d-%s",replace(trim(var.domain_name , "."),".","-"))
dns_name = var.domain_name
visibility = "public"
}
locals {
sec_name_servers = [
"pdns93.net.",
"pdns94.biz.",
"pdns93.com.",
"pdns93.org.",
]
}
resource "google_dns_record_set" "add_ns_records" {
name = google_dns_managed_zone.selected.dns_name
rrdatas = concat(local.sec_name_servers,google_dns_managed_zone.selected.name_servers)
ttl = 86400
type = "NS"
managed_zone = google_dns_managed_zone.selected.name
}
When Terraform creates a google_dns_managed_zone, the zone automatically gets created with NS records specific to Google Cloud (nameservers they provide that the zone will live on). Terraform does not import these NS records into state, so all future attempts to add or manipulate NS records in any Google Cloud Zone will fail, citing that the record set already exists: 1 2
google_dns_record_set.clouddns_ns: Error creating DNS RecordSet: googleapi: Error 409: The resource 'entity.change.additions[0]' named 'domain.com. (NS)' already exists, alreadyExists.
Additionally make sure you are using the latest terraform version.
$ terraform -v
You will not change the name servers there, as the NS records (usually) are being configured at the domain registrar - not in Cloud DNS. Unless the registrar would be Google Domains, your code might be running against the wrong site. When updating NS in Cloud DNS (in case this may even be possible), but not the registrar, you might end up with broken DNS resolution.
Adding / removing NS is generally a strange concept, as one may add this type of record once and then forgets about it... besides, Cloud DNS has 100% guaranteed uptime and it distributes quickly.
The default NS to use would be eg:
ns-cloud-c1.googledomains.com.
ns-cloud-c2.googledomains.com.
ns-cloud-c3.googledomains.com.
ns-cloud-c4.googledomains.com.
Related
After transferring a domain from another registrar to AWS, I can't get it verified in the Certificate Manager. I created a hosted zone, the CNAME records created by the Certificate Manager are there, I tried with the DNS tester - the records seem good. However it still says "pending validation". I tried a few times, waited a couple of days and it doesn't seem it will work.
I'm totally out of ideas, any help?
DNS validation require 2 things to be setup correctly. Record Name and Record Value
Check if you're correctly setting these in Route53. Reference Doc here: https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html
Now 2 issues which are very common
In the Record Name part confirm that you're not adding your domain name in the value. _X is the only part you have to copy-paste. If you copy _X.YourDomain then 'YourDomain' part is duplicated
Record Value ends with . (a period / dot). Don't remove that period
You can verify the settings from https://mxtoolbox.com/ it has various configurations like A record, CNAME, DNS Validation, etc.
I have one question to define the dns records. In this url (https://cloud.google.com/dns/docs/records), I read
Note: Adding the # symbol in this field causes the record to fail.
This generates some doubts, until now whenever I had defined the records in Google Cloud DNS, instead of using # I left it empty (thus referring to $ ORIGIN)
This is so?
that is, for example
example.com. 300 IN TXT "v = spf1 xxxxxxxxxxxxxxxxxxxxxxxxx"
example.com. 300 IN MX 10 server.domain.com.
Thank you very much
I have used Terragrunt to orchestrate the creation of a non-default AWS VPC.
I've got S3/DynamoDB state mgmt, and the VPC code is a module. I have the 'VPC environment' terraform.tfvars code checked into a second repo as per the terragrunt README.md.
I created a second module which will eventually create hosts in this VPC but for now just aims to output its ID. I have created a separate 'hosts environment' / terraform.tfvars for the instantiation of this module.
I run terragrunt apply in the VPC environment directory - VPC created
I run terragrunt apply a second time in the hosts environment directory - output directive doesn't work (no error, but incorrect, see below).
This is a precursor to one day running a terragrunt apply-all in the parent directory of the VPC/hosts environment directories; my reading of the docs suggest using a terraform_remote_state data source to expose the VPC ID, so I specified access like this in the data.tf file of the hosts module:
data "terraform_remote_state" "vpc" {
backend = "s3"
config {
bucket = "myBucket"
key = "keyToMy/vpcEnvironment.tfstate"
region = "stateRegion"
}
}
Then, in the hosts module outputs.tf, I specified an output to check assignment:
output "mon_vpc" {
value = "${data.terraform_remote_state.vpc.id}"
}
When I run (2) above, it exits with:
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
Outputs:
mon_vpc = 2018-06-02 23:14:42.958848954 +0000 UTC
Questions:
I'm going wrong setting up the code so that the hosts environment is configured to correctly acquire the VPC ID from the already-existing VPC (terraform state file) - any advice on what to change here would be appreciated.
It does look like I've managed to acquire the date of when the VPC was created rather than its ID, which given the code is perplexing - anyone know why?
I'm not using community modules - all hand rolled.
EDIT: In response to Brandon Miller, here is a bit more. In my VPC module, I have an outputs.tf containing among other outputs:
output "aws_vpc.mv.id-op" {
value = "${aws_vpc.mv.id}"
}
and the vpc.tf contains
resource "aws_vpc" "mv" {
cidr_block = "${var.vpcCidr}"
enable_dns_support = true
enable_dns_hostnames = true
tags = {
Name = "mv-vpc-${var.aws_region}"
}
}
As this cfg results in a vpc being created, and as most of the parameters are <computed>, I assumed state would contain sufficient data for other modules to refer to by consulting state (I assumed at first that terraform used the AWS API for this under the bonnet, rather than consulting a different state key).
EDIT 2: Read all of #brendan-miller's answer and following comments first.
Use of periods causes a problem as it confuses terraform (see Brendan's answer for the specification format below):
Error: output 'mon_vpc': unknown resource 'data.aws_vpc.mv-ds' referenced in variable data.aws_vpc.mv-ds.vpc.id
You named your output aws_vpc.mv.id-op but when you retrieve it you are retrieving just id. You could try
data.terraform_remote_state.vpc.aws_vpc.mv.id
but im not sure if Terraform will complain about the additional .. However the format should always be
data.terraform_remote_state.<name of the remote state module>.<name of the output>
You mentioned wanting to be able to get this info with the AWS API. That is also possible by using the aws_vpc data source. Their example uses id, but you can also use any tag you used on your vpc.
Like this:
data "aws_vpc" "default" {
filter {
name = "tag:Name"
values = ["example-vpc-name"]
}
}
Then you can use this for the id
${data.aws_vpc.default.id}
In addition this retrieves all tags set, for example:
${data.aws_vpc.default.tags.Name}
And the cidr block
${data.aws_vpc.default.cidr_block}
As well as some other info. This can be very useful for storing and retrieving things about your VPC.
I have two domain names in aws route53:
bar.org
mybar.org
i am trying to generate Letsencrypt certificate using ruby based hook of dns-01 challenge ( https://gist.github.com/joshgarnett/02920846fea35f738d3370fd991bb0e0)
I am generating certificate for the domain "mybar.org", so my domains.txt contains the name as:
mybar.org
when i try to run dehydrated -c i get the following error:
RRSet with DNS name _acme-challenge.mybar.org. is not permitted in zone bar.org.
why does it try to add RRSet in bar.org instead of mybar.org? How do i get it working?
ruby based dns hook linked in the question has a bug at the following line at find_hosted_zone function while finding the hosted zone index out of available Route53 zones.
index = hosted_zones.index { |zone| domain.end_with?(zone.name.chop)
}
index is derived based on the zone ends with the give domain name. Since my domain name "mybar.org" evaluates to true with "bar.org" (other available zone), it returns index of that zone. So this needs a PR to solve the issue.
in my case it worked fine while i modified the code as:
index = hosted_zones.index { |zone| zone.name.chop.end_with?(domain)
}
I'm trying to add a PTR DNS record in Google Cloud DNS and I'm getting an error every time I save the file through the command console. I have added other entries and they are working as expected.
{
"kind": "dns#resourceRecordSet",
"name": "xxx.xx.148.146.in-addr.arpa.",
"rrdatas": [
"mail.mydomain.com."
],
"ttl": 60,
"type": "PTR"
}
The error I receive is Invalid value for 'entity.change.additions[0].name
I've tried following the example here and it doesn't work https://groups.google.com/forum/#!msg/cloud-dns-discuss/quaYSpZImQg/QANCaDOzp3AJ
The error you are getting is due to the PTR record's "name:" field. Google servers check this field's domain part (everything after the first dot) to be equal to the domain specified as dns_name when the managed zone (zone file) was created, i.e. is reflected in the zone's SOA record.
When it come to PTR records, said records can NOT be placed into the same zone (aka managed-zone in G lingo) as the rest of domain records: said PTRs are to be placed under a separate zone file, a separate domain for all intents and purposes. Think of it as a reverse domain. This domain's name is conditioned by the subnet the PTR's IP belongs to. For instance, a PTR record that looks up IP 1.2.3.4 would be placed inside a zone named 3.2.1.in-addr.arpa. In said zone, one would find PTR records relating IP 1.2.3.4 and the rDNS result 4.3.2.1.in-addr.arpa
So, in your case, make sure you have a zone with dns_name xx.148.146.in-addr.arpa. (more on that here), into which you can then place your PTR records for IPs starting with 146.148.xx.