Porkbun integration seems to be broken only for '@' host updating #330

New Issue

saavagebueno · 2025-11-20T04:22:48-05:00

saavagebueno commented

2025-11-20 04:22:48 -05:00

Originally created by @cohenchris on GitHub (Nov 25, 2023).

TLDR: For root domain updates (using '@' in the host field), the Porkbun integration is failing.

Is this urgent: Semi-urgent
DNS provider(s) you use: Porkbun
Program version: latest as of 11/24/23 (sha256:fc65d8f5588a6b25a4021bb0b2c1de94ea42d4a96b9be705edeb1a2183c8352d)
Running version latest built on 2023-11-17T14:08:09.354Z (commit ba2e777)
What are you using to run the container: docker-compose
Extra information (optional)

Logs:

2023-11-24T17:35:38-08:00 INFO Updating record [domain: mydomain.com | host: @ | provider: porkbun | ip: ipv4] to use <public.ip.address.redacted>
2023-11-24T17:35:39-08:00 ERROR HTTP status is not valid: 400: {"status":"ERROR","message":"Edit error: We were unable to edit the DNS record."}

Configuration file (remove your credentials!):

{
  "settings": [
    {
      "provider": "porkbun",
      "domain": "mydomain.com",
      "host": "@",
      "api_key": "apikeyhere",
      "secret_api_key": "secretapikeyhere",
      "ip_version": "ipv4"
    },
    {
      "provider": "porkbun",
      "domain": "mydomain2.com",
      "host": "hostnamehere",
      "api_key": "apikeyhere"
      "secret_api_key": "secretapikeyhere"
      "ip_version": "ipv4"
    }
  ]
}

Host OS:
Arch Linux

This started happening over a week ago, figured I'd wait it out to see if it was on Porkbun's end.
Quick summary - when I try to update a root domain ('@') using this tool, I get a generic 400 error. I do have a second domain, though, and I use this tool to update a subdomain of that second domain. This one still works.

I am open to providing more logs, but there really isn't much to give. The root cause is probably as simple as Porkbun having changed their APIs.

Originally created by @cohenchris on GitHub (Nov 25, 2023). **TLDR**: For root domain updates (using '@' in the host field), the Porkbun integration is failing. 1. Is this urgent: Semi-urgent 2. DNS provider(s) you use: Porkbun 3. Program version: latest as of 11/24/23 (sha256:fc65d8f5588a6b25a4021bb0b2c1de94ea42d4a96b9be705edeb1a2183c8352d) `Running version latest built on 2023-11-17T14:08:09.354Z (commit ba2e777)` 4. What are you using to run the container: docker-compose 5. Extra information (optional) Logs: ```log 2023-11-24T17:35:38-08:00 INFO Updating record [domain: mydomain.com | host: @ | provider: porkbun | ip: ipv4] to use <public.ip.address.redacted> 2023-11-24T17:35:39-08:00 ERROR HTTP status is not valid: 400: {"status":"ERROR","message":"Edit error: We were unable to edit the DNS record."} ``` Configuration file (**remove your credentials!**): ```json { "settings": [ { "provider": "porkbun", "domain": "mydomain.com", "host": "@", "api_key": "apikeyhere", "secret_api_key": "secretapikeyhere", "ip_version": "ipv4" }, { "provider": "porkbun", "domain": "mydomain2.com", "host": "hostnamehere", "api_key": "apikeyhere" "secret_api_key": "secretapikeyhere" "ip_version": "ipv4" } ] } ``` Host OS: Arch Linux This started happening over a week ago, figured I'd wait it out to see if it was on Porkbun's end. Quick summary - when I try to update a root domain ('@') using this tool, I get a generic 400 error. I do have a second domain, though, and I use this tool to update a subdomain of that second domain. This one still works. I am open to providing more logs, but there really isn't much to give. The root cause is probably as simple as Porkbun having changed their APIs.

saavagebueno added the Status: 🗯️ Waiting for feedback Category: Provider update ♻️Category: Config problem 📝 labels 2025-11-20 04:22:48 -05:00

saavagebueno closed this issue

2025-11-20 04:22:48 -05:00

saavagebueno commented

2025-11-20 04:22:49 -05:00

@cohenchris commented on GitHub (Nov 27, 2023):

Update: After nearly 2 weeks of this issue, and having changed nothing, it seems to have inexplicably fixed itself.

@cohenchris commented on GitHub (Nov 27, 2023): Update: After nearly 2 weeks of this issue, and having changed nothing, it seems to have inexplicably fixed itself.

saavagebueno commented

2025-11-20 04:22:49 -05:00

@lgnmcrules commented on GitHub (Feb 7, 2024):

I have this same issue

@lgnmcrules commented on GitHub (Feb 7, 2024): I have this same issue

saavagebueno commented

2025-11-20 04:22:49 -05:00

@qdm12 commented on GitHub (Feb 8, 2024):

Please try with the latest image released :2.6, it contains many fixes done recently.
If it still fails, what error do you get in your logs?

@qdm12 commented on GitHub (Feb 8, 2024): Please try with the latest image released `:2.6`, it contains many fixes done recently. If it still fails, what error do you get in your logs?

saavagebueno commented

2025-11-20 04:22:50 -05:00

@ilovepancakes95 commented on GitHub (Feb 8, 2024):

Please try with the latest image released :2.6, it contains many fixes done recently. If it still fails, what error do you get in your logs?

I am having same issue too. I get following in the logs right after the 2024-02-08T22:49:53Z INFO Updating record [domain: mydomain.com | host: @ | provider: porkbun | ip: ipv4] to use X.X.X.X line.

2024-02-08T22:49:55Z ERROR HTTP status is not valid: 400: Edit error: We were unable to edit the DNS record.

@ilovepancakes95 commented on GitHub (Feb 8, 2024): > Please try with the latest image released `:2.6`, it contains many fixes done recently. If it still fails, what error do you get in your logs? I am having same issue too. I get following in the logs right after the `2024-02-08T22:49:53Z INFO Updating record [domain: mydomain.com | host: @ | provider: porkbun | ip: ipv4] to use X.X.X.X` line. `2024-02-08T22:49:55Z ERROR HTTP status is not valid: 400: Edit error: We were unable to edit the DNS record.`

saavagebueno commented

2025-11-20 04:22:50 -05:00

@qdm12 commented on GitHub (Feb 9, 2024):

@ilovepancakes95 thanks for the feedback! Can you try pulling the latest image and run it again? It now contains more error context (commit 1697697b81) to know where this edit error comes from (for example getting record IDs, or creating record or updating record)

Also, are you sure you followed steps in https://kb.porkbun.com/article/190-getting-started-with-the-porkbun-api and that your domain has API access enabled? 🤔

@qdm12 commented on GitHub (Feb 9, 2024): @ilovepancakes95 thanks for the feedback! Can you try pulling the latest image and run it again? It now contains more error context (commit 1697697b8107c38b41a51bded53bae78efd60ab1) to know where this edit error comes from (for example `getting record IDs`, or `creating record` or `updating record`) Also, are you sure you followed steps in https://kb.porkbun.com/article/190-getting-started-with-the-porkbun-api and that your domain has API access enabled? 🤔

saavagebueno commented

2025-11-20 04:22:50 -05:00

@ilovepancakes95 commented on GitHub (Feb 9, 2024):

@ilovepancakes95 thanks for the feedback! Can you try pulling the latest image and run it again? It now contains more error context (commit 1697697) to know where this edit error comes from (for example getting record IDs, or creating record or updating record)

Also, are you sure you followed steps in https://kb.porkbun.com/article/190-getting-started-with-the-porkbun-api and that your domain has API access enabled? 🤔

Before updating to your build with the latest commit I did add in the Resolver Address ENV variable since I was getting other errors based on local IP being resolved not matching the WAN IP (I am using split DNS) and the Porkbun errors have now seemingly gone away and the container is healthy and the web interface and logs show no more errors. So not sure if these two things were related or not but will keep monitoring. Even when I did have the Porkbun error mentioned, the A record was still getting updated on initial run of the container, and would say "Success" but after 5 minutes when it would go to update again, that is when the errors started. Will let you know if they crop up again.

Sort of unrelated, but I also noticed that when there were Porkbun errors about the A record not updating and unhealthy errors because of the split DNS issue, that the healthchecks.io ping was still reporting at "Success". Healthchecks does implement an explicit fail feature, I believe by appending "/fail" to the end of the URL used to hit the UUID. Perhaps implementing that so "Success" only gets reported if the IP update is actually successful and the container is healthy, otherwise if any errors or bad status, report 'Fail" to Healthchecks. Otherwise, as currently functioning, it is simply a way to see if the container itself is up or not rather than a way to tell if DDNS updates are actually working.

@ilovepancakes95 commented on GitHub (Feb 9, 2024): > @ilovepancakes95 thanks for the feedback! Can you try pulling the latest image and run it again? It now contains more error context (commit [1697697](https://github.com/qdm12/ddns-updater/commit/1697697b8107c38b41a51bded53bae78efd60ab1)) to know where this edit error comes from (for example `getting record IDs`, or `creating record` or `updating record`) > > Also, are you sure you followed steps in https://kb.porkbun.com/article/190-getting-started-with-the-porkbun-api and that your domain has API access enabled? 🤔 Before updating to your build with the latest commit I did add in the Resolver Address ENV variable since I was getting other errors based on local IP being resolved not matching the WAN IP (I am using split DNS) and the Porkbun errors have now seemingly gone away and the container is healthy and the web interface and logs show no more errors. So not sure if these two things were related or not but will keep monitoring. Even when I did have the Porkbun error mentioned, the A record was still getting updated on initial run of the container, and would say "Success" but after 5 minutes when it would go to update again, that is when the errors started. Will let you know if they crop up again. Sort of unrelated, but I also noticed that when there were Porkbun errors about the A record not updating and unhealthy errors because of the split DNS issue, that the healthchecks.io ping was still reporting at "Success". Healthchecks does implement an explicit fail feature, I believe by appending "/fail" to the end of the URL used to hit the UUID. Perhaps implementing that so "Success" only gets reported if the IP update is actually successful and the container is healthy, otherwise if any errors or bad status, report 'Fail" to Healthchecks. Otherwise, as currently functioning, it is simply a way to see if the container itself is up or not rather than a way to tell if DDNS updates are actually working.

saavagebueno commented

2025-11-20 04:22:50 -05:00

@qdm12 commented on GitHub (Feb 9, 2024):

the A record was still getting updated on initial run of the container, and would say "Success" but after 5 minutes when it would go to update again, that is when the errors started. Will let you know if they crop up again.

Ah maybe it's rate limiting you, since it would not resolve your domain name correctly possibly, so it would try every 5 minutes. If it resolves it and it matches your public IP, no update is sent to Porkbun so it shouldn't rate limit you. Let's keep an eye on this, I'll re-close this issue but feel free to comment back.

Healthchecks does implement an explicit fail feature, I believe by appending "/fail" to the end of the URL used to hit the UUID

Done in ec4411e12d 😉 For /fail, /0 and /1 (exit codes)

@qdm12 commented on GitHub (Feb 9, 2024): > the A record was still getting updated on initial run of the container, and would say "Success" but after 5 minutes when it would go to update again, that is when the errors started. Will let you know if they crop up again. Ah maybe it's rate limiting you, since it would not resolve your domain name correctly possibly, so it would try every 5 minutes. If it resolves it and it matches your public IP, no update is sent to Porkbun so it shouldn't rate limit you. Let's keep an eye on this, I'll re-close this issue but feel free to comment back. > Healthchecks does implement an explicit fail feature, I believe by appending "/fail" to the end of the URL used to hit the UUID Done in ec4411e12d55f3803233ed9c13751e41d0e570a0 😉 For /fail, /0 and /1 (exit codes)

saavagebueno commented

2025-11-20 04:22:50 -05:00

@ilovepancakes95 commented on GitHub (Feb 9, 2024):

Done in ec4411e 😉 For /fail, /0 and /1 (exit codes)

Damn, you're fast! Thank you, that's awesome.

@ilovepancakes95 commented on GitHub (Feb 9, 2024): > Done in [ec4411e](https://github.com/qdm12/ddns-updater/commit/ec4411e12d55f3803233ed9c13751e41d0e570a0) 😉 For /fail, /0 and /1 (exit codes) Damn, you're fast! Thank you, that's awesome.

saavagebueno referenced this issue

2025-11-20 04:25:58 -05:00

[PR #611] [MERGED] fix(ipv6): add JSON IPv6 suffix parameter #760

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ddns-updater#330