SOA details not settable when using powerdns_zone

[c33s]

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.

[mbag]

it seems like you are asking 2 questions here. Regarding the second one the soa_edit_api is setting SOA-EDIT-API which is described here: https://doc.powerdns.com/authoritative/domainmetadata.html#soa-edit-api We are not converting SOA-EDIT-API to SOA-EDIT-DNSUPDATE this is done by PowerDNS server as described in their documentation. The PowerDNS has made SOA-EDIT-API rules equivalent to SOA-EDIT-DNSUPDATE rules not the provider.

[mbag]

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

Here we are limited with what PowerDNS API exposes and enables us to set when creating zone: https://doc.powerdns.com/authoritative/http-api/zone.html#zone

Unless all SOA details are settable via PowerDNS API, the provider will not be able to make them settable.

[c33s]

@mbag thank you for you time to answer :)

i try to descibe the core problem better. it is not about setting this or that config value for powerdns it is about being able to use the provider without incresing the serial manually. it makes no difference for me to add a dedicated SOA record powerdns_record or being able to set it with powerdns_zone (in the provider. of course the api don't have these keys)

from UX perspective the user simply want to

• add a zone
• set SOA record and/or its values
• add reords
• have automatically increasing serials if changes happen in a zone (means the zone data or any record in it)

if under the hood multiple api calls or only one are fired don't matter. as you described it is not possible to set SOA via the zone api. that means we have to handle the SOA record by using powerdns_zone or under the hood with a 2nd api call which creates a powerdns_zone. is it a "problem" if you add all SOA parameters to the providers powerdns_zone and under the hood the zone is created and then a SOA record is created by the provider filling in all the values provided in the powerdns_zone? is it a hard requirement that the provider exposes the api 1:1? shouldn't a terraform provider abstact the api that it is easily usable?

if it is a real requirement to have a 1:1 "connection to the api" what is the intended way for being able to create zone and multiple records while editing records automatically increases the serial without having a conflict with terraform? now the sutiation is quite unhandy as having a SOA record via powerdns_record leads to an error if you use soa_edit_api with for example DEFAULT (you make an initially value of for example 2020122201 for the serial, add a new A record. powerdns automatically increases the serial to 2020122202 and terraform complany that the state in the powerdns_record SOA resource is not matching).

so how to overcome this without disabling the whole powerdns serial feature and increasing the serial manually (and everytime forgetting to do it and wondering why the dns replicas are not updating)?
what is intended way to use this provider? how you are doing it? don't you set the soa record and leave it a.misconfigured.powerdns.server? do you manually increase the serial manually? ...? as the older issue has no upvotes i am wondering if nobody is using it or i am doing something completly wrong.

do you know what i mean? i am not native english so please ask if i explained something unclear.

[mbag]

have automatically increasing serials if changes happen in a zone (means the zone data or any record in it)

by adding this, the provider would become more than a thin client. It would need to keep up with Powerdns server's logic on when to updated serial. And also be aware if all changes to the zone, described in .tf file were done successfully. And in case of failure half-way through terraform apply I don't know if it's possible to execute additional call.

is it a hard requirement that the provider exposes the api 1:1?

it's not, but it's not that easy to combine mutliple API calls (the example of this would be implementing #63 which I still haven't gotten around to). The NS record in this case is different as it doesn't change dynamically as the SOA does. And also provider doesn't have to keep some logic on it's side to make decisions when to change NS server and when not, like in case of SOA.

what is intended way to use this provider? how you are doing it? don't you set the soa record and leave it a.misconfigured.powerdns.server? do you manually increase the serial manually?

I don't have misconfigured powerdns server. But if I had to change SOA, I would do it outside of the .tf files, because it's not like you have to change a.misconfigured.powerdns.server every time you run terraform apply. And powerdns does automatic increasing of the serial for you. I would change it using curl or something similar only if a.misconfigured.powerdns.server appears in SOA record, because that would mean I'm dealing with new zone, or new deployment.

But if you know how to solve this problem, I'm opened to reviewing the pull request or helping with concrete implementation.

[jbe-dw]

Hello,

Well, SOA is put in the RRSet of the zone, but as told, you can't put it when the zone is created. It must be treated as a classic record. I ran in the same issue as you are experiencing. I have a glimpse of a solution that I need to ensure. I first wished to overwrite the serial in the provider directly but I think it's not a good design.

What I'd like to achieve is:

• Split the SOA records in a map or several variables into my tf code. Thus setting the Serial Part as a single variable
• The API exposes the Serial in a single Field that is retrieved in feat: Add PowerDNS Zone Data #72
• You can then build your SOA content from the set of variables (or the map) and the retrived Serial. This way, if nothing is changed, the computed SOA content should match the current SOA content and would not trigger a change.

This strategy is viable only if you use the soa_edit_api (the DEFAULT is a good one). With the soa_edit_api set to a strategy, the serial from the SOA is supposed to be recomputed by the server. Then if you change any other values in the SOA you can set the serial to whatever it will be replaced and trigger notifications to the slaves as well.

[jbe-dw]

Hello,

Running this code works with the patch I submitted in #72 (you don't need data even if I added it) and SOA_EDIT_API set to default (but I any option but none should work):

# Variables
variable "test_info_soa" {
  type = map(any)
}
test_info_soa = {
  primary_ns = "dns1.test.info."
  email      = "hostmaster.test.info."
  refresh    = 10800
  retry      = 3600
  expire     = 604800
  ttl        = 600
}

# Create the zone
resource "powerdns_zone" "test_info" {​
  name         = "test.info."
  kind         = "master"
  account      = "infra"
  nameservers  = ["ns1.test.info.", "ns2.test.info."]
  soa_edit_api = "DEFAULT"
}​

# Compute the SOA
locals {​
  test_info_soa = join(" ", [var.test_info_soa.primary_ns,
    var.test_info_soa.email,
    powerdns_zone.test_info.serial,
    var.test_info_soa.refresh,
    var.test_info_soa.retry,
    var.test_info_soa.expire,
  var.test_info_soa.ttl])
}​

# Create a record
resource "powerdns_record" "test_info_soa" {​
  zone    = "test.info."
  name    = "test.info."
  type    = "SOA"
  ttl     = "3600"
  records = [local.test_info_soa]
  set_ptr = false
}​

This code will:

• Create the zone and register details like the current serial in your tfstate
• Dynamically compute your SOA using the current serial
• Add the SOA record correctly. Terraform will ensure dependency.

Modifying the code (add/remove/update other records) will trigger a refresh each time, and SOA value will be updated in your tfstate but will match the computed value, not triggering an update. The other changes will update the serial, as PowerDNS will do it itself.

I have planned to have a separate tfstate with this data (zone, SOA and nameservers A value) and another with the records. The zone lifecycle will occasionally require these records update when the content will be frequently updated by users with their code.

@c33s you can pull the "forkPreview" branch from my fork and build the provider for a test. You would have to install it manually then.

Regards

[selfuryon]

As workaround I use this settings in powerdns configuration:

default-soa-content=ns-1.@ admin.@ 0 10800 3600 604800 3600

@ automatically expands to domain

[jbe-dw]

Thank you @selfuryon for the settings. It is new in 4.4 and I have to say that I was talking to the PDNS team before christmas to know when the would release the 4.4 but they didn't mention this new seting and continue to work on the TF provider.

This is a great workaround if you want to apply a standard SOA configuration. I am going to check this, even if I'll continue to say that the PR is harmless, it may become useless for a lot of adopters with this new setting though.

[jbe-dw]

Hello here,

I have definitely chosen to use @selfuryon tips. Since Feb, there has been several terraform release. We are struggling on other projects with their imposed idea of always displaying external changes. There's often differences between providers and software behaviour (like in openstack) and we always have plans that should be blank filled with loads of external changes (ie a tag not set in terraform but the software setting it as an empty list just pops up in the plan ...)

This is why my proposal has become a terrible idea as it would quite often shows the changed serial in the plan.