the powerdns docs say that the type (=kind) should have MASTER or SLAVE in it for replication. i am not sure about the case of Native but with master and slave they are in caps.

https://doc.powerdns.com/authoritative/modes-of-operation.html#master-slave-setup-requirements

but setting the kind to MASTER

resource "powerdns_zone" "..." {
  name    = "example.com."
  kind    = "MASTER"
...

when calling terraform apply results everytime in:

  ~ powerdns_zone....
      kind: "Master" => "MASTER"

so you have to write Master to not get a diff on each terraform apply

Hi there,

I have problems with adding ip addresses of the master dns server for a slave zone.
The only way is to add it manually in my postgresql database via:
INSERT INTO domains (name, master, type) VALUES ('test.example.de', '192.168.10.11, 192.168.10.12', 'SLAVE');

In this example my powerdns server want to become a slave of the zone test.example.de. The master of this zone is: 192.168.10.11 & 192.168.10.12

I have no opportunity to configure this scenario via terraform. I can only use:
resource "powerdns_zone" "testexamplede_zone" {
name = "test.example.de."
kind = "Slave"
nameservers = [""]
}

Where can I add the ip addresses for the master of this zone?

Best regards
networksecadmin

Terraform Version

Terraform v0.12.17

Affected Resource(s)

powerdns_record

Terraform Configuration Files

resource "powerdns_record" "dev-minio" {
  zone    = "example.com."
  name    = "dev-minio.example.com."
  type    = "A"
  ttl     = 360
  set_ptr = true
  records = ["172.20.30.14"]
}

Expected Behavior

terraform destroy should delete A and PTR records

Actual Behavior

terraform destroy deletes only A record

Steps to Reproduce

1. terraform apply configuration above
   Terraform creates A record and PTR record (because set_ptr = true)
2. terraform destroy
   Terraform deletes only A record.

Hi,

Now that recent Mac uses a new CPU architecture (Apple Silicon) based on ARM64 and with compatible Terraform builds, could you please build this provider for darwin arm64 ?

Thanks!

this issue is related to #43 and #45

currently the provider has still its problem, it can't handle soa records without manual intervention. even having the "add option soa_edit_api" #40 it conflicts with custom SOA records.

if i only define a zone, i don't have to manually set the soa record.

resource "powerdns_zone" "foobar" {
  name        = "example.net."
  kind        = "MASTER"
  soa_edit_api = "DEFAULT"
  nameservers = [...]
}

but i cannot configure all soa fields and will end up with an invalid soa record:

a.misconfigured.powerdns.server hostmaster.example.net 2020122102 10800 3600 604800 3600

if i add a custom soa recoard additionally to the zone

resource "powerdns_record" "foobar3" {
  zone    = "example.net."
  name    = "example.net."
  type    = "SOA"
  ttl     = 3600
  records = ["ns1.example.com. hostmaster.example.com. 2020122101 10800 3600 360000 300"]
}

it will work in the first run but as i add A records i will get conflicting SOA records.

can anyone use powerdns with this provider without manual intervention? are only docs missing or does it simply not work?

as @ion1 commented #43 (comment) a special placeholder in the soa record like <auto> (@ion1 suggested 0) would help.

an alternative would be to allow to set all SOA data with the powerdns_zone.

today i also noticed that with the zone we set soa_edit_api which is for SOA-EDIT-DNSUPDATE and not SOA-EDIT as i asumed from #29 (which of course make sense, as it is the zone i set and not the server config)

just to list the values from the powerdns docs here:

https://doc.powerdns.com/authoritative/dnssec/operational.html#possible-soa-edit-values

• SOA-EDIT
  • INCREMENT-WEEKS
  • INCEPTION-EPOCH
  • INCEPTION-INCREMENT
  • EPOCH

https://doc.powerdns.com/authoritative/dnsupdate.html#soa-edit-dnsupdate-settings

• SOA-EDIT-DNSUPDATE
  • DEFAULT
  • INCREASE
  • EPOCH
  • SOA-EDIT
  • SOA-EDIT-INCREASE

it would really make sense to improve the docs here but to improve the docs it would be required that one of the implementing devs describe what is the right way for handling this.

Currently link to powerdns_zone is missing from website/powerdns.erb. Documentation was updated, but we need to add link to it.

It's no longer used for building and releasing this provider

Affected Resource(s)

• powerdns_record

Expected Behavior

The powerdns_record resource should have an optional attribute 'comment' which is passed to the API when creating to add a comment for the record. This would allow us to easily tag records by their module, and indicate that they are managed by terraform, in setups where terraform does not have complete control over all the zone.

Important Factoids

We run PowerDNS with the PowerDNS-Admin frontend to maintain all our zones. Terraform handles records which relate to the terraform-managed environments. The problem is identifying which records are terraform-managed when viewing via the web GUI as we are not able to add comments to the records to indicate this.

In addition, terraform does not support the disabled flag for records, but this is not really an issue as why would you create a disabled record? It might be worth checking that an existing record has not been disabled via another method, though.

Since @splashx and I ( @mbag ) adopted this provider, we will work to make it compatible with TF v0.12.
In order to do so, the PRs that are currently open will be merged, so that once we start working on v0.12 compatibility changes, we don't have to solve compatibility of these PRs as well.

Once done, final version that works with Terraform v0.11 will be released and then I'll start refactoring provider code to adhere to Terraform v0.12.

Hi!

I want to add recursor/auth configuration (it's the same one exists for auth server but not shown in docs) as resource to this provider.

I think I can add it like this:

resource "powerdns_configuration" "root" {
    name = "allow-from",                    #string
    type = "ConfigSetting",                 #string
    value = "127.0.0.0/8, 10.0.0.0/8"       #string
}

Terraform Version

OpenTofu v1.6.2

Expected Behavior

As an Open Source terraform user, I am moving to OpenTofu. As a security sensitive user, I want to verify the GPG signatures on the packages in the registry.

As both, I expect the signature for the module in the OpenTofu registry to be up to date :)

Actual Behavior

- Installed hashicorp/powerdns v1.5.0. Signature validation was skipped due to the registry not containing GPG keys for this provider

Steps to Reproduce

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

1. tofu init when using the powerdns provider

Steps to Fix

Please create a ticket here with your public GPG key, so OpenTofu can validate the signatures:

https://github.com/opentofu/registry/issues/new?assignees=&labels=provider-key%2Csubmission&projects=&template=provider_key.yml&title=Provider+Key%3A+

masters attribute support has been added in #59 but the validation there is more strict than needed. PowerDNS supports port for master values but the resource expects only a valid IP.

Terraform Version

v0.12.25

Affected Resource(s)

powerdns_zone

Terraform Configuration Files

resource "powerdns_zone" "zone" {
  name = var.zone_name
  kind = "Slave"
  masters = ["192.168.0.1:5553"]
}

Debug Output

Error: values in masters list attribute must be valid IPs

  on ../powerdns/zone/main.tf line 10, in resource "powerdns_zone" "zone":
  10: resource "powerdns_zone" "zone" {

This is a request to add an option to the provider that disables TLS verification of the PowerDNS server's certificate. For example:

provider powerdns {
  server_url      = "https://our.pdns.server"
  api_key         = "..."
  skip_tls_verify = true
}

i would suggest to add a full example in the docs on how to config a whole domain including ZONE, SOA, MX, A, CNAME, ALIAS with an info that powerdns should configures with soa-api-default = INCEPTION-INCREMENT to make the provider work out of the box. i am quite sure this will help to quickstart with powerdns without much effort.

having a config like that, running terraform apply works.

resource "powerdns_record" "SOA_example_com" {
  zone    = "example.com."
  name    = "example.com."
  type    = "SOA"
  ttl     = 3600
  records = ["ns1.c33s.net. hostmaster.example.com. 2019090208 10800 3600 360000 300"]
}

the soa record is created. everything fine. changing the serial number afterwards from 2019090208 to 2019090210 and running terraform apply again resulting in an error.

deleting the record with sql delete from records where id=49; and running terraform apply again correctly creates the record.

i don't had the problem with version 0.1.0 of this provider but don't needed to update my config for quite a while. today i wanted to change some config and thought it would be a good thing to update. then i got this error. downgrading to 0.1.0 does not help. i have not changed my terraform config or updated terraform. i only added a zone and an a record.

Expected Behavior

the soa record should be updated normally

Actual Behavior

Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

-/+ powerdns_record.SOA_example_com (new resource required)
      id:                 "example.com.:::SOA" => <computed> (forces new resource)
      name:               "example.com." => "example.com."
      records.#:          "1" => "1"
      records.161965187:  "" => "ns1.mydns.net. hostmaster.example.com. 2019090208 10800 3600 360000 300" (forces new resource)
      records.3839120863: "ns1.mydns.net. hostmaster.example.com. 2019090206 10800 3600 360000 300" => "" (forces new resource)
      ttl:                "3600" => "3600"
      type:               "SOA" => "SOA"
      zone:               "example.com." => "example.com."


Plan: 1 to add, 0 to change, 1 to destroy.

Do you want to perform these actions in workspace "production"?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

powerdns_record.SOA_example_com: Destroying... (ID: example.com.:::SOA)

Error: Error applying plan:

1 error(s) occurred:

* powerdns_record.SOA_example_com (destroy): 1 error(s) occurred:

* powerdns_record.SOA_example_com: Error deleting PowerDNS Record: Error deleting record: example.com. SOA, reason: "No SOA found for domain 'example.com.'"

References

maybe related to PowerDNS/pdns#4705

I think it would be great to add the ability to import resources (zones and records).

I will try to provide a working PR, since in most cases this just needs a pass-through state importer definition in the schema:

		Importer: &schema.ResourceImporter{
			State: schema.ImportStatePassthrough,
		},

Maybe I'm missing something obvious - but how do you get a notify sent when you use the pdns api via the terraform provider? It's correctly updating SOA serial number in the zone upon creations/removals, but API calls to PDNS do not trigger a notify to downstream servers unless you explicitly ask it to and there does not appear to be any equivalent to the 'NOTIFY-DNSUPDATE' zone metadata for API edits to have it happen automatically.

Terraform Version

Terraform v1.2.8
on linux_amd64
+ provider registry.terraform.io/hashicorp/aws v4.65.0
+ provider registry.terraform.io/hashicorp/external v2.3.1
+ provider registry.terraform.io/hashicorp/vault v3.15.0
+ provider registry.terraform.io/hashicorp/vsphere v2.3.1
+ provider registry.terraform.io/pan-net/powerdns v1.5.0

Your version of Terraform is out of date! The latest version
is 1.4.6. You can update by downloading from https://www.terraform.io/downloads.html

Affected Resource(s)

powerdns_record

While evaluating this plugin we noticed it is deleting and recreating records on otherwise minor changes. Note the following diff output:

 # powerdns_record.pdns_instance_a_record[0] must be replaced
-/+ resource "powerdns_record" "pdns_instance_a_record" {
      ~ id      = "[Snip FQDN]:::A" -> (known after apply)
        name    = "[Snip FQDN]."
      ~ records = [ # forces replacement
          - "[Snip Subnet].135",
          + "[Snip Subnet].32",
        ]
      ~ ttl     = 60 -> 5 # forces replacement
        type    = "A"
        zone    = "[Snip zone]"
    }

In auditing the API calls it is sending rrsets to the server with a changetype of DELETE. This is an aggressive approach that can cause service impacts as the DNS record will cease to exist between when it is deleted and recreated, instead of simply being updated. PowerDNS does not require the record to be deleted in these cases, a REPLACE rrset without the delete will cause the record to be replaced by PowerDNS in one API call.

Provider Version

terraform-provider-powerdns_v1.4.1

Expected Behavior

PowerDNS should have been sent a single REPLACE rrset per record.

Actual Behavior

PowerDNS was sent a DELETE rrset, deleting the record unnecessarily.

Steps to Reproduce

Apply a TTL or record change to a powerdns_record resource. Other fields were not verified but assumed to behave the same way.

Important Factoids

None

References

https://doc.powerdns.com/authoritative/http-api/zone.html#rrset

Version

terraform version

Terraform v0.11.7
+ provider.null v1.0.0
+ provider.powerdns v0.1.0
+ provider.vault v1.0.0

Error

terraform plan

Error: Error refreshing state: 1 error(s) occurred:

* provider.powerdns: Error setting up PowerDNS client: Get http://ns.service.consul:8081/api/v1/servers: EOF

Solution

Pointing to a powerdns 4.1.1 instance resolves the issue.

This Terraform provider is scheduled to be archived on September 27th, 2018. HashiCorp may archive providers when they have insufficient activity to maintain them at a level consistent with our open source guidelines and community expectations.

What does archiving mean?

1. The code repository and all commit, issue, and PR history will still be available.
2. Existing released binaries will remain available on the releases site and available to terraform init.
3. Documentation for the provider will remain on the Terraform website.
4. Issues and pull requests are not being monitored, merged, or added.
5. No new releases will be published.
6. Nightly acceptance tests may not be run.

If anyone from the community is willing to maintain this provider, please reach out to the Terraform Provider Development Program at [email protected].

I am trying to run acceptance tests. I've prepared an empty PowerDNS (4.0.5) instance and its API is available on http://127.0.0.1:8081. Now when I run tests, i get:

$ make testacc
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test $(go list ./... |grep -v 'vendor') -v  -timeout 120m
?   	github.com/terraform-providers/terraform-provider-powerdns	[no test files]
=== RUN   TestProvider
--- PASS: TestProvider (0.00s)
=== RUN   TestProviderImpl
--- PASS: TestProviderImpl (0.00s)
=== RUN   TestAccPDNSRecord_A
--- FAIL: TestAccPDNSRecord_A (0.02s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-a: 1 error(s) occurred:

		* powerdns_record.test-a: Failed to create PowerDNS Record: Error creating record set: redis.sysa.xyz:::A, reason: "DNS Name 'redis.sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_WithPtr
--- FAIL: TestAccPDNSRecord_WithPtr (0.01s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-a-ptr: 1 error(s) occurred:

		* powerdns_record.test-a-ptr: Failed to create PowerDNS Record: Error creating record set: redis.sysa.xyz:::A, reason: "DNS Name 'redis.sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_WithCount
--- FAIL: TestAccPDNSRecord_WithCount (0.01s)
	testing.go:434: Step 0 error: Error applying: 2 error(s) occurred:

		* powerdns_record.test-counted[0]: 1 error(s) occurred:

		* powerdns_record.test-counted.0: Failed to create PowerDNS Record: Error creating record set: redis-0.sysa.xyz:::A, reason: "DNS Name 'redis-0.sysa.xyz' is not canonical"
		* powerdns_record.test-counted[1]: 1 error(s) occurred:

		* powerdns_record.test-counted.1: Failed to create PowerDNS Record: Error creating record set: redis-1.sysa.xyz:::A, reason: "DNS Name 'redis-1.sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_AAAA
--- FAIL: TestAccPDNSRecord_AAAA (0.01s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-aaaa: 1 error(s) occurred:

		* powerdns_record.test-aaaa: Failed to create PowerDNS Record: Error creating record set: redis.sysa.xyz:::AAAA, reason: "DNS Name 'redis.sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_CNAME
--- FAIL: TestAccPDNSRecord_CNAME (0.01s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-cname: 1 error(s) occurred:

		* powerdns_record.test-cname: Failed to create PowerDNS Record: Error creating record set: redis.sysa.xyz:::CNAME, reason: "DNS Name 'redis.sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_HINFO
--- FAIL: TestAccPDNSRecord_HINFO (0.01s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-hinfo: 1 error(s) occurred:

		* powerdns_record.test-hinfo: Failed to create PowerDNS Record: Error creating record set: redis.sysa.xyz:::HINFO, reason: "DNS Name 'redis.sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_LOC
--- FAIL: TestAccPDNSRecord_LOC (0.01s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-loc: 1 error(s) occurred:

		* powerdns_record.test-loc: Failed to create PowerDNS Record: Error creating record set: redis.sysa.xyz:::LOC, reason: "DNS Name 'redis.sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_MX
--- FAIL: TestAccPDNSRecord_MX (0.01s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-mx: 1 error(s) occurred:

		* powerdns_record.test-mx: Failed to create PowerDNS Record: Error creating record set: sysa.xyz:::MX, reason: "DNS Name 'sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_NAPTR
--- FAIL: TestAccPDNSRecord_NAPTR (0.01s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-naptr: 1 error(s) occurred:

		* powerdns_record.test-naptr: Failed to create PowerDNS Record: Error creating record set: sysa.xyz:::NAPTR, reason: "DNS Name 'sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_NS
--- FAIL: TestAccPDNSRecord_NS (0.01s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-ns: 1 error(s) occurred:

		* powerdns_record.test-ns: Failed to create PowerDNS Record: Error creating record set: lab.sysa.xyz:::NS, reason: "DNS Name 'lab.sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_SPF
--- FAIL: TestAccPDNSRecord_SPF (0.01s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-spf: 1 error(s) occurred:

		* powerdns_record.test-spf: Failed to create PowerDNS Record: Error creating record set: sysa.xyz:::SPF, reason: "DNS Name 'sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_SSHFP
--- FAIL: TestAccPDNSRecord_SSHFP (0.01s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-sshfp: 1 error(s) occurred:

		* powerdns_record.test-sshfp: Failed to create PowerDNS Record: Error creating record set: ssh.sysa.xyz:::SSHFP, reason: "DNS Name 'ssh.sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_SRV
--- FAIL: TestAccPDNSRecord_SRV (0.01s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-srv: 1 error(s) occurred:

		* powerdns_record.test-srv: Failed to create PowerDNS Record: Error creating record set: _redis._tcp.sysa.xyz:::SRV, reason: "DNS Name '_redis._tcp.sysa.xyz' is not canonical"
=== RUN   TestAccPDNSRecord_TXT
--- FAIL: TestAccPDNSRecord_TXT (0.01s)
	testing.go:434: Step 0 error: Error applying: 1 error(s) occurred:

		* powerdns_record.test-txt: 1 error(s) occurred:

		* powerdns_record.test-txt: Failed to create PowerDNS Record: Error creating record set: text.sysa.xyz:::TXT, reason: "DNS Name 'text.sysa.xyz' is not canonical"
FAIL
FAIL	github.com/terraform-providers/terraform-provider-powerdns/powerdns	0.177s
make: *** [testacc] Error 1

Affected Resource(s)

• powerdns_record

Terraform Configuration Files

resource "powerdns_record" "test-a" {
  zone = "sysa.xyz"
	name = "redis.sysa.xyz"
	type = "A"
	ttl = 60
	records = [ "1.1.1.1", "2.2.2.2" ]
}

Expected Behavior, Actual Behavior

Acceptance tests should have passed. Adding a dot at the end of name field fixes the problem.

So, my question is:

• If this is expected, should we fix hcl strings in resource_powerdns_record.go to have dots in name?
• If not expected, maybe add a dot substitution inside a code?

I would gladly make a PR, but let's discuss, first.

See issue #29 for details.

Hi

When modifying (adding/changing/removing) the nameservers list, terraform tries to recreate the zone rather than just making the ammendments

Terraform version: 0.12.24
Powerdns Provider Version: v1.4.0

Affected Resource(s)

Please list the resources as a list, for example:

• powerdns_zone

Terraform Configuration Files

variable "master_zones" {
  type = map
}

variable "master_zones_nameservers" {
  type = list
}

master_zones = {
  "1" = "zone1.domain.com."
  "2" = "2.6.in-addr.arpa."
}

master_zones_soa_edit_api = "EPOCH"
master_zones_nameservers = ["nameserver1.domain.com.", "nameserver2.domain.com.","nameserver3.domain.com.", "nameserver4.domain.com."]

resource "powerdns_zone" "master_zone" {
  for_each     = var.master_zones
  name         = each.value
  kind         = "master"
  nameservers  = var.master_zones_nameservers
  soa_edit_api = var.master_zones_soa_edit_api
}

Expected Behavior

Zone should remain, and nameserver/s should get updated

Actual Behavior

Zone gets recreated, from scratch

Steps to Reproduce

1. terraform apply

Important Factoids

Power DNS version: 4.3.1

Any help/advice is appreciated

Thanks

This issue was reported here.

TL;DR:

• Version 1.1.0:

• Proposed patch

⚠️ Because we don't implement Update, it's important to note that in all cases the record is recreated. So in cases where the record doesn't exist in the state file it's because it failed to create a new one (apply didn't finish with success).

Long Version

Steps to reproduce:

Environment with existing record

Environment:

$ cat terraform.tfstate
{
  "version": 4,
  "terraform_version": "0.12.7",
  "serial": 24,
  "lineage": "5d15eb7d-2f44-4172-ac9d-494cb2534cd2",
  "outputs": {},
  "resources": []
}
$ cat test.tf
resource "powerdns_record" "foobar" {
  zone    = "sysa.xyz."
  name    = "something.sysa.xyz."
  type    = "A"
  ttl     = 300
  records = ["127.0.0.1"]
}
$ terraform apply  -auto-approve
powerdns_record.foobar: Creating...
powerdns_record.foobar: Creation complete after 0s [id=something.sysa.xyz.:::A]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
$ curl -X GET -H "X-Api-Key: secret" http://localhost:8081/api/v1/servers/localhost/zones/sysa.xyz. -s  | jq '.rrsets[].name | match("something.sysa.xyz.")'
{
  "offset": 0,
  "length": 19,
  "string": "something.sysa.xyz.",
  "captures": []
}
$ cat terraform.tfstate
{
  "version": 4,
  "terraform_version": "0.12.7",
  "serial": 26,
  "lineage": "5d15eb7d-2f44-4172-ac9d-494cb2534cd2",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "powerdns_record",
      "name": "foobar",
      "provider": "provider.powerdns",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "something.sysa.xyz.:::A",
            "name": "something.sysa.xyz.",
            "records": [
              "127.0.0.1"
            ],
            "set_ptr": null,
            "ttl": 300,
            "type": "A",
            "zone": "sysa.xyz."
          },
          "private": "bnVsbA=="
        }
      ]
    }
  ]
}
$

1. Changing the value of records to []:

$ cat terraform.tfstate
{
  "version": 4,
  "terraform_version": "0.12.7",
  "serial": 48,
  "lineage": "5d15eb7d-2f44-4172-ac9d-494cb2534cd2",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "powerdns_record",
      "name": "foobar",
      "provider": "provider.powerdns",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "something.sysa.xyz.:::A",
            "name": "something.sysa.xyz.",
            "records": [
              "127.0.0.1"
            ],
            "set_ptr": null,
            "ttl": 300,
            "type": "A",
            "zone": "sysa.xyz."
          },
          "private": "bnVsbA=="
        }
      ]
    }
  ]
}
$ curl -X GET -H "X-Api-Key: secret" http://localhost:8081/api/v1/servers/localhost/zones/sysa.xyz. -s  | jq '.rrsets[].name | match("something.sysa.xyz.")'
{
  "offset": 0,
  "length": 19,
  "string": "something.sysa.xyz.",
  "captures": []
}
$ cat test.tf
resource "powerdns_record" "foobar" {
  zone    = "sysa.xyz."
  name    = "something.sysa.xyz."
  type    = "A"
  ttl     = 300
  records = []
}
$ terraform apply  -auto-approve
powerdns_record.foobar: Refreshing state... [id=something.sysa.xyz.:::A]
powerdns_record.foobar: Destroying... [id=something.sysa.xyz.:::A]
powerdns_record.foobar: Destruction complete after 0s
powerdns_record.foobar: Creating...
powerdns_record.foobar: Creation complete after 0s [id=something.sysa.xyz.:::A]

Apply complete! Resources: 1 added, 0 changed, 1 destroyed.
$ cat terraform.tfstate
{
  "version": 4,
  "terraform_version": "0.12.7",
  "serial": 51,
  "lineage": "5d15eb7d-2f44-4172-ac9d-494cb2534cd2",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "powerdns_record",
      "name": "foobar",
      "provider": "provider.powerdns",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "something.sysa.xyz.:::A",
            "name": "something.sysa.xyz.",
            "records": null,
            "set_ptr": null,
            "ttl": 300,
            "type": "A",
            "zone": "sysa.xyz."
          },
          "private": "bnVsbA=="
        }
      ]
    }
  ]
}
$ curl -X GET -H "X-Api-Key: secret" http://localhost:8081/api/v1/servers/localhost/zones/sysa.xyz. -s  | jq '.rrsets[].name | match("something.sysa.xyz.")'

2. Changing the value of records to [""] (same conditions/environment as 1):

$ cat terraform.tfstate
{
  "version": 4,
  "terraform_version": "0.12.7",
  "serial": 54,
  "lineage": "5d15eb7d-2f44-4172-ac9d-494cb2534cd2",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "powerdns_record",
      "name": "foobar",
      "provider": "provider.powerdns",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "something.sysa.xyz.:::A",
            "name": "something.sysa.xyz.",
            "records": [
              "127.0.0.1"
            ],
            "set_ptr": null,
            "ttl": 300,
            "type": "A",
            "zone": "sysa.xyz."
          },
          "private": "bnVsbA=="
        }
      ]
    }
  ]
}
$ curl -X GET -H "X-Api-Key: secret" http://localhost:8081/api/v1/servers/localhost/zones/sysa.xyz. -s  | jq '.rrsets[].name | match("something.sysa.xyz.")'
{
  "offset": 0,
  "length": 19,
  "string": "something.sysa.xyz.",
  "captures": []
}
$ cat test.tf
resource "powerdns_record" "foobar" {
  zone    = "sysa.xyz."
  name    = "something.sysa.xyz."
  type    = "A"
  ttl     = 300
  records = [""]
}
$ terraform apply  -auto-approve
powerdns_record.foobar: Refreshing state... [id=something.sysa.xyz.:::A]
powerdns_record.foobar: Destroying... [id=something.sysa.xyz.:::A]
powerdns_record.foobar: Destruction complete after 0s
powerdns_record.foobar: Creating...

Error: Failed to create PowerDNS Record: Error creating record set: something.sysa.xyz.:::A, reason: "Record something.sysa.xyz./A '': Parsing record content (try 'pdnsutil check-zone'): missing field at the end of record content ''"

  on test.tf line 1, in resource "powerdns_record" "foobar":
   1: resource "powerdns_record" "foobar" {


$ cat terraform.tfstate
{
  "version": 4,
  "terraform_version": "0.12.7",
  "serial": 56,
  "lineage": "5d15eb7d-2f44-4172-ac9d-494cb2534cd2",
  "outputs": {},
  "resources": []
}
$ curl -X GET -H "X-Api-Key: secret" http://localhost:8081/api/v1/servers/localhost/zones/sysa.xyz. -s  | jq '.rrsets[].name | match("something.sysa.xyz.")'
$

If the suggestion from here is applied, the behavior is:

A. Using records = []

$ terraform apply  -auto-approve
powerdns_record.foobar: Refreshing state... [id=something.sysa.xyz.:::A]
powerdns_record.foobar: Destroying... [id=something.sysa.xyz.:::A]
powerdns_record.foobar: Destruction complete after 0s
powerdns_record.foobar: Creating...

Error: Couldn't fetch PowerDNS Record: Unknown record ID format

  on test.tf line 1, in resource "powerdns_record" "foobar":
   1: resource "powerdns_record" "foobar" {


$ cat terraform.tfstate
{
  "version": 4,
  "terraform_version": "0.12.7",
  "serial": 42,
  "lineage": "5d15eb7d-2f44-4172-ac9d-494cb2534cd2",
  "outputs": {},
  "resources": []
}
$ curl -X GET -H "X-Api-Key: secret" http://localhost:8081/api/v1/servers/localhost/zones/sysa.xyz. -s  | jq '.rrsets[].name | match("something.sysa.xyz.")'
$

B. Using records = [""]:

$ cat terraform.tfstate
{
  "version": 4,
  "terraform_version": "0.12.7",
  "serial": 44,
  "lineage": "5d15eb7d-2f44-4172-ac9d-494cb2534cd2",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "powerdns_record",
      "name": "foobar",
      "provider": "provider.powerdns",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "id": "something.sysa.xyz.:::A",
            "name": "something.sysa.xyz.",
            "records": [
              "127.0.0.1"
            ],
            "set_ptr": null,
            "ttl": 300,
            "type": "A",
            "zone": "sysa.xyz."
          },
          "private": "bnVsbA=="
        }
      ]
    }
  ]
}
$ curl -X GET -H "X-Api-Key: secret" http://localhost:8081/api/v1/servers/localhost/zones/sysa.xyz. -s  | jq '.rrsets[].name | match("something.sysa.xyz.")'
{
  "offset": 0,
  "length": 19,
  "string": "something.sysa.xyz.",
  "captures": []
}
$ cat test.tf
resource "powerdns_record" "foobar" {
  zone    = "sysa.xyz."
  name    = "something.sysa.xyz."
  type    = "A"
  ttl     = 300
  records = [""]
}
$ terraform apply  -auto-approve
powerdns_record.foobar: Refreshing state... [id=something.sysa.xyz.:::A]
powerdns_record.foobar: Destroying... [id=something.sysa.xyz.:::A]
powerdns_record.foobar: Destruction complete after 0s
powerdns_record.foobar: Creating...

Error: Failed to create PowerDNS Record: Error creating record set: something.sysa.xyz.:::A, reason: "Record something.sysa.xyz./A '': Parsing record content (try 'pdnsutil check-zone'): missing field at the end of record content ''"

  on test.tf line 1, in resource "powerdns_record" "foobar":
   1: resource "powerdns_record" "foobar" {


$ cat terraform.tfstate
{
  "version": 4,
  "terraform_version": "0.12.7",
  "serial": 46,
  "lineage": "5d15eb7d-2f44-4172-ac9d-494cb2534cd2",
  "outputs": {},
  "resources": []
}
$ curl -X GET -H "X-Api-Key: secret" http://localhost:8081/api/v1/servers/localhost/zones/sysa.xyz. -s  | jq '.rrsets[].name | match("something.sysa.xyz.")'
$

Terraform Version

$terraform --version
Terraform v0.12.20
+ provider.powerdns v1.3.0

Affected Resource(s)

• powerdns_record

Terraform Configuration Files

resource "powerdns_record" "a" {
  zone = "example.com"
  name = "test.example.com."
  type = "A"
  ttl  = "86400"
  records = ["192.168.1.1"]
}

Debug Output

https://gist.github.com/m33x-7/4714f03fc12e04640fd075098a1f9ae4#file-apply-trace-1
https://gist.github.com/m33x-7/4714f03fc12e04640fd075098a1f9ae4#file-apply-trace-2
https://gist.github.com/m33x-7/4714f03fc12e04640fd075098a1f9ae4#file-tfstate-after-apply
https://gist.github.com/m33x-7/4714f03fc12e04640fd075098a1f9ae4#file-destroy-trace-1
https://gist.github.com/m33x-7/4714f03fc12e04640fd075098a1f9ae4#file-tfstate-after-destroy

pdns server log:

HTTP ISE for "/api/v1/servers/localhost/zones/example.com": STL Exception: Parsing record content (try 'pdnsutil check-zone'): missing field at the end of record content '  2020072800 28800 7200 604800 86400'

API curl:

curl -v -H "X-API-Key: <--snip-->" http://localhost:8081/api/v1/servers/localhost/zones/example.com
* About to connect() to localhost port 8081 (#0)
*   Trying localhost...
* Connected to localhost (localhost) port 8081 (#0)
> GET /api/v1/servers/localhost/zones/example.com HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8081
> Accept: */*
> X-API-Key: <--snip-->
>
< HTTP/1.1 500 Internal Server Error
< Connection: close
< Content-Length: 21
< Content-Type: text/plain; charset=utf-8
< Server: PowerDNS/4.1.6
<
* Closing connection 0

Panic Output

None

Expected Behavior

On error from the API terraform bails out and doesn't create the record

Actual Behavior

Terraform created the record, even though there was an error, but doesn't see that it's been created so attempts to create it again on further applys, and can't destroy the record.

Steps to Reproduce

1. Create a malformed SOA record, e.g. it's missing MNAME and / or RNAME
2. terraform apply with the above config, record is created
3. terraform apply or terraform plan attempts to create the record again, even though it's in the statefile
4. terraform destroy removes state, but doesn't remove the record

Important Factoids

Malformed SOA record was created by PowerAdmin, likely down to a configuration fault on my end. However outside of using the API DNS lookups are / were working fine.

Fixing the SOA record resolves the issue.

References

None

to create a SOA record for a domain i have to use powerdns_record like this:

resource "powerdns_record" "SOA_example_com" {
  zone    = "example.com."
  name    = "example.com."
  type    = "SOA"
  ttl     = 3600
  records = ["dns1.example2.com. hostmaster.example.com. 2019120101 10800 3600 3600000 3600"]
}

which creates a record with this entry. if i have set my soa_edit_api to empty according #29 it works like charm but of course it is much better to have set the serial automatically. so if i set soa_api_edit to INCEPTION-INCREMENT i get a conflict because the serial got increased automatically and isn't equal to the serial set in the terraform config before:

• running terraform apply creates the soa record (with the config above)
• the serial gets increased automatically
• running terraform apply again results in this:

      id:                 "example.com.:::SOA" => <computed> (forces new resource)
      name:               "example.com." => "example.com."
      records.#:          "1" => "1"
      records.xxxxxxxxx9: "ns1.example2.com. hostmaster.example.com. 2019120102 10800 3600 3600000 3000" => "" (forces new re
      records.xxxxxxxxx2: "" => "ns1.example2.com. hostmaster.example.com. 2019120101 10800 3600 3600000 3000" (forces new re
      ttl:                "3600" => "3600"
      type:               "SOA" => "SOA"
      zone:               "example.com." => "example.com."

so how to use this provider to create an initial SOA record but increase the serial without this conflict?

After some misunderstanding on how to use some of the provider features, namely:
https://github.com/terraform-providers/terraform-provider-powerdns/issues/55 - how to add multiple values for the same record
https://github.com/terraform-providers/terraform-provider-powerdns/issues/54 - how to set priority for MX records

I'm opening this issue so that clarification for these 2 cases is added to documentation.

The tests are failing after merging #74 the reason was identified, I'm just waiting for confirmation in this thread: #74 (comment)

If this simple fix would not fix the issue, I will revert commit until issue with tests and import is resolved.

Actual Behavior

When creating reverse pointers, one has to resort to terraform primitives to transform a given IP to a revere transcription for the PTR record. This works for IPv4, but not for IPv6. For v6 ptrs one could resort to external commands, but this would no longer be idempotent.

Expected Behavior

Provide a utility function that accepts a forward IP address as name and produces a PTR record which it forwards to pdns, e.g. name = to_ptr("192.168.1.1"). Another alternative is to provide a dedicated ptr record resource, similar to the Aure DNS Provider.

Hi there,

When trying to add a records via Terraform, it will try to add data to an unknown column.

column name : changed_when, in table records.

added it manually as a workaround in my powerdns database in the records table.

Official PowerDns schema do not have this column, so I think removing it from your API is not a bad idea.

br.

Formatting of the example code is broken, since it's missing newline

Hi there,

Thank you for merging my last patch. Do you plan to do a release any time soon ?

Regards

Hi there,

Thank you for opening an issue.
I want to know if terraform support the ALIAS type for powerdns ,if yes, can you let me know how to configure my code ? Thanks in advance.

Terraform Version

Terraform v0.11.7

• provider.aws v2.38.0
• provider.powerdns v1.2.0

Affected Resource(s)

Can not use terraform to create alias type records for powerdns

Terraform Configuration Files

resource "powerdns_record" "test" {
  zone    = "${var.powerdns_test_external_zone}"
  name    = "test.${var.powerdns_test_external_zone}"
  ttl     = 300
  type    = "ALIAS"
  records = ["xxxxxx.cloudfront.cn."]
}

I also change "ALIAS" to "ANAME" , it was not work.

Debug Output

Error: Error applying plan:

1 error(s) occurred:

* powerdns_record.test: 1 error(s) occurred:

* powerdns_record.test: Failed to create PowerDNS Record: Error creating record set: test.test.cn.:::ACNAME, reason: "RRset test.test.cn. IN ACNAME: unknown type given"

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

A release with the new soa_edit_api for zone would be awesome

This issue was originally opened by @poblin-orange as hashicorp/terraform#12339. It was migrated here as part of the provider split. The original body of the issue is below.

The powerdns record resource is very powerfull and convenient.
As part of our automations, a resource to define zone would me most usefull (we use shell scripts as the zone resource is not avail in terraform

Terraform Version

0.8.4

Affected Resource(s)

Missing zone resource

Terraform Configuration Files

Debug Output

Panic Output

Expected Behavior

Actual Behavior

Steps to Reproduce

Important Factoids

References

Terraform Version

Terraform v0.12.21

provider.powerdns v1.3.0

Affected Resource(s)

powerdns_record

Terraform Configuration Files

resource "powerdns_record" "spf" {
  zone    = "example.com."
  name    = "example.com."
  type    = "TXT"
  ttl     = 60
  records = ["\"v=spf1 mx -all\""]
}

resource "powerdns_record" "dmarc" {
  zone    = "example.com."
  name    = "example.com."
  type    = "TXT"
  ttl     = 60
  records = ["\"v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; aspf=s; adkim=s\""]
}

resource "powerdns_record" "dkim" {
  zone    = "example.com."
  name    = "example.com."
  type    = "TXT"
  ttl     = 60
  records = ["\"v=DKIM1 ;k=rsa; s=email; p=Msdsdfsdfsdfsdfsdfsdfsdfsdfsdfsfdfsdfsdfsdfds\""]
}

resource "powerdns_record" "caa1" {
  zone    = "example.com."
  name    = "example.com."
  type    = "CAA"
  ttl     = 60
  records = ["0 issue \"letsencrypt.org\""]
}

resource "powerdns_record" "caa2" {
  zone    = "example.com."
  name    = "example.com."
  type    = "CAA"
  ttl     = 60
  records = ["0 issuewild \";\""]
}

Expected Behavior

Terraform creates the defined CAA- and TXT-Records.

Actual Behavior

Terraform just juggles around the records. At first run, maybe the spf-record is created and caa1.
On the next apply, caa1 is replaced by caa2 and spf is replaced by maybe dmarc.

Steps to Reproduce

1. terraform apply
2. look at your dns entries
3. terraform apply
4. check dns again, you should have different entries now

Terraform Version

Terraform v0.12.21

• provider.powerdns v1.3.0

Affected Resource(s)

powerdns_record

It is not possible at the moment to create MX-records with this provider, because the priority-field can not be set.
Therefor, trying to create a mx-record results in an error.
Could this field be added to the powerdns_record resource?

This is related to #93 , but even with that fixed I am not sure this is fully fixed problem.

The reason is that currently provider, as well as PowerDNS API requires one to specify the zone in which to create a record.

But for PTR is it really tricky.

I.e. 10.1.2.3 will be usually record 3.2.1 in zone 10.in-addr.arpa. (because 10.0.0.0/8 is usually configured like that), some one can try do something like:

resource "powerdns_record" "ptrrecord" {
  zone    = "${replace(join(".", reverse(split(".", aws_instance.instance.private_ip))), "/^\\b(?:\\d{1,3}.){3}/", "")}.in-addr.arpa."
  name    = "${join(".", reverse(split(".", aws_instance.instance.private_ip)))}.in-addr.arpa."
  type    = "PTR"
  ttl     = 60
  records = ["${var.hostname}.example.com."]
}

But then some other private zones are /16 or /24 by default, and so record needs to go to a different zone:

Example: 172.29.8.9, will go into 29.172.in-addr.arpa, because 172.16.0.0/12 is usually setup as multiple /16 zones.

resource "powerdns_record" "ptrrecord" {
  zone    = "${replace(join(".", reverse(split(".", aws_instance.instance.private_ip))), "/^\\b(?:\\d{1,3}.){2}/", "")}.in-addr.arpa."
  name    = "${join(".", reverse(split(".", aws_instance.instance.private_ip)))}.in-addr.arpa."
  type    = "PTR"
  ttl     = 60
  records = ["${var.hostname}.example.com."]
}

Similarly for 192.168.0.0/16 and 100.64.0.0/10. For the rest, I am pretty sure it is common to use /24 due to delegation reasons and it being most granular.

So, as you can see it not easy to creat a single expression for zone, that do work when one has different zone layouts. This is not the end of the worlds, but we do have some AWS, GCE, etc clusters, and some are in 172.16.0.0/12, and now we are migrating more towards 10.0.0.0/8 subnetworks (not due to space constraints, but rather to manage better IPs and prevent network collisions with some other networks we manage)

For a powerdns install on 4.4 that I just did, Creating a fresh domain, I seem to have incremental 500s. It'll apply like one of the records, and then fail with 500s for the rest, then I run it again, and it gets one further.

The zones get created fine, but the record changes do not.

Terraform Version

Terraform v0.14.3
+ provider registry.terraform.io/pan-net/powerdns v1.4.0

Affected Resource(s)

powerdns_record

Terraform Configuration Files

Here's the entire terraform repo as it stands, with the domain entries I wanted to run. Haven't gotten very far with it yet.
sample.zip

Debug Output

https://gist.github.com/dkowis/30b1a1b41936523ac65d201f9061adf3

Expected Behavior

I should've just been able to do a single terraform apply, and everything was awesome.

Actual Behavior

I had to incrementally apply the stuff. The server is a vanilla powerdns install, using a sqlite3 backend. Literally I have only configured the web API, and the sqlite3 backend.

When deleting the state, I get errors, but things actually did get deleted, leaving me with an invalid state

Steps to Reproduce

all covered in the ascii cast.

PowerDNS 4.4

If you pass in an upper case name, it gets created, but is converted to lowercase in powerDNS. When you run a destroy on the same state, it does not delete the record assumingely because the case does not match. I would think that a case conversion should happen in the provider or throw an error because of case.

I'm new to PowerDNS. I was not able to find a configuration setting the enables uppercase records.

Terraform Version

0.13.5

Affected Resource(s)

powerdns_record

Terraform Configuration Files

resource "powerdns_record" "A" {
  zone    = "example.com."
  name    = "Test.example.com."
  type    = "A"
  ttl     = 300
  records = ["192.168.0.110"]
}

Expected Behavior

If it creates the record, it should be able to destroy it.

Actual Behavior

Creates the record, but does not destroy

Steps to Reproduce

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

1. terraform apply
2. terraform destroy

Important Factoids

References

How about updating terraform sdk (and maybe other packages) to v2 version?

Can do it in future PRs

This issue was originally opened by @joelcollin as hashicorp/terraform#9209. It was migrated here as part of the provider split. The original body of the issue is below.

Terraform Version

terraform 0.7.3

Affected Resource(s)

Provider: powerdns

Terraform Configuration Files

# Configure the PowerDNS provider
provider "powerdns" {
api_key = "changeme"
server_url = "http://powerdns:8081"
}

Debug Output

None.

Panic Output

None.

Expected Behavior

In our infrastructure, we use PowerDNS resources for some instances, but not for others. The ones requiring powerdns records to be added are located in a Google Compute Engine project and those not requiring it are in another. Unfortunately, across projects, we have a firewall rule that prevents connecting to the PowerDNS server. We do not want to fork our module for this small difference.

To address the issue, we used the "count" property in our powerdns ressources and set it to 0. This is useless because the powerdns provider attempts to validate the API on initialization. This is useless if there are no resources to be

TL;DR: connection to PowerDNS server should only happen if at least one resource is to be provisioned.

Actual Behavior

Connection to PowerDNS happens even if no resource are created.

Steps to Reproduce

1. Add a powerdns provider, set it to an unreachable address
2. Set a variable named "powerdns_enabled" with default 1.
3. In terraform.tfvars, set powerdns_enabled = 0
4. In your resource file, add a powerdns_record ressource with count = ${var.powerdns_enabled}
5. Run terraform plan

Problem is in the client.NewClient constructor-like factory:

client.ApiVersion, err = client.detectApiVersion()

This is probably a design decision, but could be moved to the first time client.newRequest is invoked to avoid being used if there are no effective ressources being provisioned.

Important Factoids

Tight firewall between projects prevents from connecting to PowerDNS for some instances that are otherwise identical.

References

None.

This issue was originally opened by @jgeorgeson as hashicorp/terraform#18396. It was migrated here as a result of the provider split. The original body of the issue is below.

Terraform Version

Terraform v0.11.7

Terraform Configuration Files

resource "powerdns_record" "foobar" {
  zone    = "example.com"
  name    = "www.example.com"
  type    = "A"
  ttl     = 300
  records = ["192.168.0.11"]
}

Additional Context

The PowerDNS REST API includes a boolean to automatically create PTR records when adding an A or AAAA record with an IP that is within an already configured reverse lookup zone. It'd be nice to make use of that in Terraform, so we can define a single resource.

References

https://doc.powerdns.com/authoritative/http-api/zone.html#record

Terraform Version

v0.14.2

Affected Resource(s)

All.

Terraform Configuration Files

terraform {
  required_providers {
    powerdns = {
      source = "pan-net/powerdns"
    }
  }
}

provider "powerdns" {
  server_url = "http://example.com/"
}

Expected Behavior

When API key isn't defined (and therefore, Terraform asks for it interactively) but the PowerDNS server URL is defined in the configuration, the provider sees the server URL parameter and talks to it.

Actual Behavior

% terraform plan
Acquiring state lock. This may take a few moments...
provider.powerdns.api_key
  REST API authentication key

  Enter a value: 1234

Releasing state lock. This may take a few moments...

Error: Missing required attribute

  on <input-prompt> line 1:
  (source code not available)

The attribute "server_url" is required, but no definition was found.

It would be nice if the provider supported setting zone metadata such as ALSO-NOTIFY and ALLOW-AXFR-FROM.

First, thanks for your great work!
Please find a new feature Request regarding Powerdns LUA Records.

Affected Resource(s)

• powerdns_record

Expected Behavior

To be able to pass LUA Records to Powerdns. https://doc.powerdns.com/authoritative/lua-records/.
I do not expect the provider to handle the LUA syntax, but just to pass LUA Record to Powerdns API. (Let Powerdns handle issues with LUA syntax..)

References:

https://godoc.org/github.com/hashicorp/terraform/helper/resource#ParallelTest
https://godoc.org/github.com/hashicorp/terraform/helper/resource#Test