Porkbun HTTP status is not valid: 400 Edit error: We were unable to edit the DNS record.

[JuicyFruiter]

ddns-update is running on synology NAS / docker /portainer / watchtower
Running version latest built on 2024-07-27T11:54:25.808Z (commit 1cd57d6)

I did a quick search for related issues and possibly discussion #508 seems like it might be related, but in my case, the DNS seems to create root and wildcard DNS records in porkbun successfully, but then the container moves to unhealthy state and I can see 3 lines of messages like this in the log repeat every 5mins:

Container logs
`

2024/08/07 13:14:39	stdout	2024-08-07T13:14:39+01:00 �[91mERROR�[0m updating record: HTTP status is not valid: 400: Edit error: We were unable to edit the DNS record.
2024/08/07 13:14:37	stdout	2024-08-07T13:14:37+01:00 �[36mINFO�[0m Updating record [domain:[mydomain] | owner: @ | provider: porkbun | ip: ipv4] to use [my.external.ip.address]
2024/08/07 13:14:37	stdout	2024-08-07T13:14:37+01:00 �[36mINFO�[0m ipv4 address of [mydomain] is 172.17.0.2 and your ipv4 address  is [my.external.ip.address]
`

config.json

{
  "settings": [
    {
      "provider": "porkbun",
      "domain": "[mydomain]",
      "host": "*,@",
      "api_key": "[my_api_key]",
      "secret_api_key": "[my_secret_key]",
      "ip_version": "ipv4"
    }  
   ]
}

I'm stuck at what to try next, any ideas?
Thanks in advance

[qdm12]

ipv4 address of [mydomain] is 172.17.0.2 and your ipv4 address is [my.external.ip.address]

Are you resolving the mydomain using an internal DNS? It seems like mydomain resolves to 172.17.0.2... You can use a different resolver (see environment variables) such as 1.1.1.1. Now the 400 error you see is due to Porkbun refusing to update a record from a certain value xyz to the same value xyz. Because ddns-updater finds there is a mismatch between the public ip address and the record value, it tries to update it, although it's already set to the correct value I think.

[qdm12]

I was probably wrong above. A few more questions 👨‍⚕️

1. Does this error disappear over time? Or does it repeat every update period?
2. On the porkbun web interface, what's the A record value?

[JuicyFruiter]

Interestingly , the wildcard.mydomain is now detecting that it’s not changed and has a status of ok, but the root record is the one that keeps attempting to update itself every 5mins and hits the failure status.

porkbun dns record shows the correct IP address of 45.128.x.x for both root and wildcard records.

Now I’m confused :)

[qdm12]

Moare questions! (also related discussion on #774)

1. Do you have any other record such as cname or alias? 🤔
2. What does https://www.nslookup.io/ resolve your root domain to? The private IP address you had, or your public IP address?
3. If step 2 gives you the wrong private ip address, try increasing your PERIOD setting. Maybe, maybe, Porkbun takes a long time to apply changes and start propagating, and this gets reinitialised when an update is received.

[JuicyFruiter]

Thanks, I hadnt seen 774, Shall I try the steps outlined about renaming the dns directly to 127.0.0.1 and restarting ddnsupdater?
In answer to your questions:

1. Any other record such as cname or alias?
   In the porkbun dns record, I have:

• A record for *.mydomain (External IP 45.128.x.x)
• A record for mydomain (External IP 45.128.x.x)
• TXT record for mydomain (v=spf1 policy)
• TXT record for _acme-challenge.mydomain (key1)
• TXT record for _acme-challenge.mydomain (key2)

2. nslookup.io correctly resolves to external IP 45.128.x.x

3. Step 2 gave the correct external IP address, but I tried increasing the period to 10m anyway. Container hit the issue straight away on launch, but like before, the @ record seems to be the one causing an issue - the webui reports that the wildcard is up to date.

[qdm12]

nslookup.io correctly resolves to external IP 45.128.x.x

So it's definitely a problem with ddns-updater not resolving your domain correctly (maybe using pihole or some internal dns). Are you sure you set RESOLVER_ADDRESS=1.1.1.1:53 and it still resolves it wrong???

[JuicyFruiter]

yes I think so, screen grab attached

[JuicyFruiter]

$ sudo docker run --rm alpine:3.20 nslookup j177381.com
Password: 
Unable to find image 'alpine:3.20' locally
3.20: Pulling from library/alpine
c6a83fedfae6: Pull complete 
Digest: sha256:0a4eaa0eecf5f8c050e5bba433f58c052be7587ee8af3e8b3910ef9ab5fbe9f5
Status: Downloaded newer image for alpine:3.20
Server:         192.168.1.1
Address:        192.168.1.1:53

Non-authoritative answer:

Non-authoritative answer:
Name:   j177381.com
Address: 45.128.139.118

[qdm12]

Ok that's super strange. What about setting RESOLVER_ADDRESS=8.8.8.8:53 or setting dns: 8.8.8.8 in the container definition? Does this fix it?

[JuicyFruiter]

I tried 8.8.8.8:53 and got the same result. I didn’t know how to dns in the container definition (synology), so in an act of frustration I deleted and recreated the container from scratch using the old config.json.
It worked first time and has been stable over night.
Thank you so much for taking the time to help, there’s a coffee/beer in your PayPal as a small thanks.

[qdm12]

I deleted and recreated the container from scratch using the old config.json.

Uh, that's odd it's now working again 🤷

Thank you so much for taking the time to help, there’s a coffee/beer in your PayPal as a small thanks.

Appreciated thanks!

[anwang168]

Is there a way to check the A‑record value directly from Porkbun first? I reviewed Porkbun’s Python and PowerShell scripts, and both appear to query Porkbun for the current A‑record and compare it against the device’s external IP before performing any update. Using nslookup doesn’t seem reliable in my setup because my UniFi router has a local DNS override. Any lookup from within the network gets routed to my local reverse proxy, which prevents me from seeing the actual external A‑record value. As a result, I’m now seeing a lot of false‑positive errors in the log.