[BUG] Adding nameserver fails

[igorakkerman]

Checklist

• I have used the latest version of terraform (if not please provide a version number).
• I have used the latest version of this terraform provider (if not please provide a version number).
• I have provided a sample .tf configuration under "Additional context".
• I have answered the following question: Is this issue reproducible in OT&E or only applies to live?

Describe the bug
Trying to create a nameserver resource in order to add DNS records for a domain before transferring it to INWX from another registrar.

To Reproduce
Create resource inwx_nameserver

Expected behavior
Nameserver resource is created.

Additional context
Output of terraform apply: (domain name changed for demonstration purposes to example.com)

Terraform will perform the following actions:

  # inwx_nameserver.example_com_master will be created
  + resource "inwx_nameserver" "example_com_master" {
      + domain      = "example.com"
      + id          = (known after apply)
      + nameservers = [
          + "ns.inwx.de",
          + "ns2.inwx.de",
        ]
      + type        = "MASTER"
    }

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

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

  Enter a value: yes

inwx_nameserver.example_com_master: Creating...
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to inwx_nameserver.example_com_master, provider "provider[\"registry.terraform.io/inwx/inwx\"]" produced an  
│ unexpected new value: Root object was present, but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Only tested in live system.

Sample .tf configuration:

resource "inwx_nameserver" "example_com_master" {
  domain = "example.com"
  type   = "MASTER"
  nameservers = [
    "ns.inwx.de",
    "ns2.inwx.de",
  ]
}

[iamdevnull]

I have a similar issue:

resource "inwx_nameserver" "xxx" {
  domain = "xxx"
  type   = "MASTER"
  nameservers = [
    "ns.inwx.de",
    "ns2.inwx.de",
    "ns3.inwx.eu"
  ]
}

│ Error: Could not add nameserver record
│ 
│   with inwx_nameserver.fuenfVorflug_at,
│   on at.tf line 1, in resource "inwx_nameserver" "xxx":
│    1: resource "inwx_nameserver" "xxx" {
│ 
│ API response not status code 1000 or 1001. Got response: {"code":2302,"details":[{"code":"DOMAIN_IN_DNS","msg":"The domain is already in the DNS"}],"msg":"Object exists","reason":"The domain is already in the
│ DNS.","reasonCode":"Error_DomainAlreadyInDNS"}
╵

Please help.

[igorakkerman]

@iamdevnull fyi as a workaround, I looked up the ID of the nameserver resource using the Python API client (https://github.com/inwx/python-client) and used terraform import to get it into the state.

[iamdevnull]

@igorakkerman thx a lot!

[iamdevnull]

@iamdevnull fyi as a workaround, I looked up the ID of the nameserver resource using the Python API client (https://github.com/inwx/python-client) and used terraform import to get it into the state.

Can you maybe share with me your code. Which output param did you use as input for tf import?

https://www.inwx.de/en/help/apidoc/f/ch02s15.html#nameserver.info

[igorakkerman]

@iamdevnull I believe I just printed the result of the API call to the console and copy-pasted the id field:

api_client.call_api(api_method="nameserver.info", method_params= { 
    "domain": "mydomain.com"
})

[simonszu]

Same problem here. I followed the hint with the python client lib, and i assume the right field is called roID, since this is present in the API response, as well as the name of the return value when someone actually creates a new zone with the terraform provider.
However, the problems persist. Maybe this is related: The import command accepts the parameter "domain:roID", thats why the ID of the zone is stored as "domain:roID" in the state. When someone creates the zone with Terraform instead of importing it, apparently only the "roID" is returned by the provider, without the "domain:" prefix.

So, after accidentally deleting all records in the zone because the output of tf plan only hints at recreating the NS record set, and not the whole zone, i am leaving my comment here, subscribe to this issue and would like to see it a bit as a usability bug as well (for example the import example command of this resource omits the name of the resource where to import to: $ terraform import inwx_nameserver example.com:2147483647 which is not a valid terraform import command).

[wombelix]

I agree that domain:id is a bit unexpected and inconvenient, I'm not sure why it was implemented like this. On a first look, this seem optional from an API perspective and could be dropped.
Anyway, the problem with the current import function is a different one in my opinion. Only domain and type are read and stored in the state (https://github.com/inwx/terraform-provider-inwx/blob/main/inwx/internal/resource/resource_nameserver.go#L251). And all the other resources, our state doesn't know anything about, are marked as ForceNew in the schema (https://github.com/inwx/terraform-provider-inwx/blob/main/inwx/internal/resource/resource_nameserver.go#L54). That combination seem to cause the issue that tf plan suggests a forces replacement of the whole Zone in basically any case if you imported it. I have to take a much deeper look, but only a few changes, like Domain or Type, should do that. Anything else is a change instead.
At least for me, the inwx_nameserver resource is not usable at this point. I try to find some time to come up with a patch.