starred/ddns-updater
1
0
Fork 0
mirror of https://github.com/qdm12/ddns-updater.git synced 2026-08-02 10:38:41 -04:00
Code Issues 312 Packages Projects Releases 10 Wiki Activity

Bug: Porkbun root domain update states failure, but IP gets updated correctly anyway (subdomains work without failure) #479

New Issue
Closed
opened 2025-11-20 04:24:26 -05:00 by saavagebueno · 9 comments
saavagebueno commented 2025-11-20 04:24:26 -05:00
Owner
Copy Link

Originally created by @mmarszal on GitHub (Dec 30, 2024).

TLDR: Porkbun DNS updates work without problem for subdomains, but root domain always delivers an error (but updates the IP anyway)

  1. Is this urgent: No

  2. DNS provider(s) you use: Porkbun

  3. Program version:

    Running version latest built on 2024-12-24T09:20:36.130Z (commit 78f3061)

  4. What are you using to run the container: docker-compose

  5. Extra information (optional)

Logs:

2024-12-29T19:06:53Z DEBUG POST https://api.porkbun.com/api/json/v3/dns/retrieveByNameType/root.domain/A/ | headers: User-Agent: DDNS-Updater quentin.mcgaw@gmail.com; Content-Type: application/json; Accept: application/json | body: {"secretapikey":"skXXX","apikey":"pk1XXX"}
2024-12-29T19:06:55Z DEBUG 200 OK | headers: X-Frame-Options: sameorigin; X-Xss-Protection: 1; mode=block; Content-Language: en-US, en; Content-Type: application/json; Set-Cookie: XXXX; path=/; secure; HttpOnly; SameSite=Lax; Expires: Thu, 19 Nov 1981 08:52:00 GMT; Cache-Control: no-store, no-cache, must-revalidate; Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; Date: Sun, 29 Dec 2024 19:06:55 GMT; Server: openresty; Pragma: no-cache; X-Content-Type-Options: nosniff; Referrer-Policy: origin | body: {"status":"SUCCESS","cloudflare":"enabled","records":[{"id":"XXX","name":"root.domain","type":"A","content":"XXX.XXX.XXX.XXX","ttl":"600","prio":"0","notes":null}]}

2024-12-29T19:06:55Z DEBUG POST https://api.porkbun.com/api/json/v3/dns/edit/root.domain/XXX | headers: User-Agent: DDNS-Updater quentin.mcgaw@gmail.com; Content-Type: application/json; Accept: application/json | body: {"secretapikey":"sk1XXX","apikey":"pk1XXX","content":"XXX.XXX.XXX.XXX","type":"A","ttl":"0","name":"@"}
2024-12-29T19:06:55Z DEBUG 400 Bad Request | headers: Cache-Control: no-store, no-cache, must-revalidate; Pragma: no-cache; Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; Date: Sun, 29 Dec 2024 19:06:55 GMT; Content-Type: application/json; Server: openresty; Set-Cookie: BUNSESSION2=XXX; path=/; secure; HttpOnly; SameSite=Lax; Expires: Thu, 19 Nov 1981 08:52:00 GMT | body: {"status":"ERROR","message":"Edit error: We were unable to edit the DNS record."}

Configuration file (remove your credentials!):

{
      "provider": "porkbun",
      "domain": "sub.root.domain,sub2.root.domain,root.domain",
      "api_key": "pk1XXX",
      "secret_api_key": "sk1XXX",
      "ip_version": "ipv4",
      "ipv6_suffix": ""
    }

Host OS: Debian 12, ddns-updater running under docker with official image

Hi everyone, I've been using ddns-updater with a few different providers, and it is mostly working quite well.
I mainly have a problem with pork bun returning an error while trying to update the root domain IP.
The funny thing is that the update works, but an error always gets returned only for the root domain (listed in logs above). All subdomains get updated properly without error. I replaced all secret information above with XXX when necessary.

Any idea what I can do to get the updates to return cleanly?

Thanks, and I appreciate the work that goes into this client!

Originally created by @mmarszal on GitHub (Dec 30, 2024). <!-- YOU CAN CHAT THERE EVENTUALLY: https://github.com/qdm12/ddns-updater/discussions --> **TLDR**: *Porkbun DNS updates work without problem for subdomains, but root domain always delivers an error (but updates the IP anyway)* 1. Is this urgent: No 2. DNS provider(s) you use: Porkbun 3. Program version: <!-- See the line at the top of your logs --> `Running version latest built on 2024-12-24T09:20:36.130Z (commit 78f3061)` 4. What are you using to run the container: docker-compose 5. Extra information (optional) Logs: ``` 2024-12-29T19:06:53Z DEBUG POST https://api.porkbun.com/api/json/v3/dns/retrieveByNameType/root.domain/A/ | headers: User-Agent: DDNS-Updater quentin.mcgaw@gmail.com; Content-Type: application/json; Accept: application/json | body: {"secretapikey":"skXXX","apikey":"pk1XXX"} 2024-12-29T19:06:55Z DEBUG 200 OK | headers: X-Frame-Options: sameorigin; X-Xss-Protection: 1; mode=block; Content-Language: en-US, en; Content-Type: application/json; Set-Cookie: XXXX; path=/; secure; HttpOnly; SameSite=Lax; Expires: Thu, 19 Nov 1981 08:52:00 GMT; Cache-Control: no-store, no-cache, must-revalidate; Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; Date: Sun, 29 Dec 2024 19:06:55 GMT; Server: openresty; Pragma: no-cache; X-Content-Type-Options: nosniff; Referrer-Policy: origin | body: {"status":"SUCCESS","cloudflare":"enabled","records":[{"id":"XXX","name":"root.domain","type":"A","content":"XXX.XXX.XXX.XXX","ttl":"600","prio":"0","notes":null}]} 2024-12-29T19:06:55Z DEBUG POST https://api.porkbun.com/api/json/v3/dns/edit/root.domain/XXX | headers: User-Agent: DDNS-Updater quentin.mcgaw@gmail.com; Content-Type: application/json; Accept: application/json | body: {"secretapikey":"sk1XXX","apikey":"pk1XXX","content":"XXX.XXX.XXX.XXX","type":"A","ttl":"0","name":"@"} 2024-12-29T19:06:55Z DEBUG 400 Bad Request | headers: Cache-Control: no-store, no-cache, must-revalidate; Pragma: no-cache; Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; Date: Sun, 29 Dec 2024 19:06:55 GMT; Content-Type: application/json; Server: openresty; Set-Cookie: BUNSESSION2=XXX; path=/; secure; HttpOnly; SameSite=Lax; Expires: Thu, 19 Nov 1981 08:52:00 GMT | body: {"status":"ERROR","message":"Edit error: We were unable to edit the DNS record."} ``` Configuration file (**remove your credentials!**): ``` { "provider": "porkbun", "domain": "sub.root.domain,sub2.root.domain,root.domain", "api_key": "pk1XXX", "secret_api_key": "sk1XXX", "ip_version": "ipv4", "ipv6_suffix": "" } ``` Host OS: Debian 12, ddns-updater running under docker with official image Hi everyone, I've been using ddns-updater with a few different providers, and it is mostly working quite well. I mainly have a problem with pork bun returning an error while trying to update the root domain IP. The funny thing is that the update works, but an error always gets returned only for the root domain (listed in logs above). All subdomains get updated properly without error. I replaced all secret information above with XXX when necessary. Any idea what I can do to get the updates to return cleanly? Thanks, and I appreciate the work that goes into this client!
saavagebueno commented 2025-11-20 04:24:27 -05:00
Author
Owner
Copy Link

@mmarszal commented on GitHub (Jan 2, 2025):

Just a quick update. I tried using the POST commands that ddns-updater uses (found from the DEBUG logs) within a rest client, and the update works perfectly without errors. I wonder if the problem lays somewhere else.

@mmarszal commented on GitHub (Jan 2, 2025): Just a quick update. I tried using the POST commands that ddns-updater uses (found from the DEBUG logs) within a rest client, and the update works perfectly without errors. I wonder if the problem lays somewhere else.
saavagebueno commented 2025-11-20 04:24:27 -05:00
Author
Owner
Copy Link

@mmarszal commented on GitHub (Jan 2, 2025):

I did some further analysis. I found how to make the request fail now. The Edit error: We were unable to edit the DNS record. error happens when ddns-updater tries to update the IP address when the IP address doesn't need a change. It looks like the pork bun API returns an error when the call tries to update the IP with the same value. I was able to check this using a REST client.

So it looks like ddns-updater is trying to update the IP when it doesn't need to.

@mmarszal commented on GitHub (Jan 2, 2025): I did some further analysis. I found how to make the request fail now. The ```Edit error: We were unable to edit the DNS record.``` error happens when ddns-updater tries to update the IP address when the IP address doesn't need a change. It looks like the pork bun API returns an error when the call tries to update the IP with the same value. I was able to check this using a REST client. So it looks like ddns-updater is trying to update the IP when it doesn't need to.
saavagebueno commented 2025-11-20 04:24:27 -05:00
Author
Owner
Copy Link

@LnLcFlx commented on GitHub (Jan 4, 2025):

I'm experiencing the same problem.

@LnLcFlx commented on GitHub (Jan 4, 2025): I'm experiencing the same problem.
saavagebueno commented 2025-11-20 04:24:28 -05:00
Author
Owner
Copy Link

@bentemple commented on GitHub (Jan 8, 2025):

I'll take a look into this

@bentemple commented on GitHub (Jan 8, 2025): I'll take a look into this
saavagebueno commented 2025-11-20 04:24:28 -05:00
Author
Owner
Copy Link

@bentemple commented on GitHub (Jan 8, 2025):

So, the "porkbun will fail if you try to update a record to the same value" is known. Was this an issue you experienced initially but are no longer getting?

How ddns-updater works, is it cycles through multiple DNS servers for each validation check (by default) checking the IP for your domain. i.e. root.domain
so, given a dns lookup of root.domain returning a value 0.0.0.0
It then goes to porkbun, with the first request you see:

2024-12-29T19:06:53Z DEBUG POST https://api.porkbun.com/api/json/v3/dns/retrieveByNameType/root.domain/A/ | headers: User-Agent: DDNS-Updater quentin.mcgaw@gmail.com; Content-Type: application/json; Accept: application/json | body: {"secretapikey":"skXXX","apikey":"pk1XXX"}
2024-12-29T19:06:55Z DEBUG 200 OK | headers: X-Frame-Options: sameorigin; X-Xss-Protection: 1; mode=block; Content-Language: en-US, en; Content-Type: application/json; Set-Cookie: XXXX; path=/; secure; HttpOnly; SameSite=Lax; Expires: Thu, 19 Nov 1981 08:52:00 GMT; Cache-Control: no-store, no-cache, must-revalidate; Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; Date: Sun, 29 Dec 2024 19:06:55 GMT; Server: openresty; Pragma: no-cache; X-Content-Type-Options: nosniff; Referrer-Policy: origin | body: {"status":"SUCCESS","cloudflare":"enabled","records":[{"id":"XXX","name":"root.domain","type":"A","content":"XXX.XXX.XXX.XXX","ttl":"600","prio":"0","notes":null}]}

the A record here has a value of "XXX.XXX.XXX.XXX"

Then, if that value it got from the DNS lookup isn't correct, it will create or update the record, but it doesn't validate that porkbun is already set to the correct value.

Because the correct value already is set on the record, you're going to get that error. That being said, this should be a transient only issue and as soon as the DNS records properly propagate, it should stop trying to update the record and won't show any more failures.

So my guess here, is that this is mostly just a transient "I just setup DDNS updater, and maybe setup a test IP prior to letting DDNS setup the DNS" issue vs a long-running issue. does that sound correct?

I think I had proposed code to do an additional validation check to ensure we don't call update if the value is already correct, but ultimately that shouldn't be necessary, though it likely is what presents this somewhat confusing error case.

You can see the logic here

So if we just change that to:

	for _, record := range records {
                if record.Content != ipStr {
		        err = p.updateRecord(ctx, client, recordType, p.owner, ipStr, record.ID)
		        if err != nil {
			        return netip.Addr{}, fmt.Errorf("updating record: %w", err)
		        }
                }
	}

I believe that would resolve this transient issue, but then it would mask the issue that some dns server has the wrong record value for your domain because the propagation hasn't happened yet. So I think it's better to have a transient error than to hide that error-case given that it should resolve itself once the new DNS record finishes propagating.

@bentemple commented on GitHub (Jan 8, 2025): So, the "porkbun will fail if you try to update a record to the same value" is known. Was this an issue you experienced initially but are no longer getting? How ddns-updater works, is it cycles through multiple DNS servers for each validation check (by default) checking the IP for your domain. i.e. root.domain so, given a dns lookup of root.domain returning a value 0.0.0.0 It then goes to porkbun, with the first request you see: ``` 2024-12-29T19:06:53Z DEBUG POST https://api.porkbun.com/api/json/v3/dns/retrieveByNameType/root.domain/A/ | headers: User-Agent: DDNS-Updater quentin.mcgaw@gmail.com; Content-Type: application/json; Accept: application/json | body: {"secretapikey":"skXXX","apikey":"pk1XXX"} 2024-12-29T19:06:55Z DEBUG 200 OK | headers: X-Frame-Options: sameorigin; X-Xss-Protection: 1; mode=block; Content-Language: en-US, en; Content-Type: application/json; Set-Cookie: XXXX; path=/; secure; HttpOnly; SameSite=Lax; Expires: Thu, 19 Nov 1981 08:52:00 GMT; Cache-Control: no-store, no-cache, must-revalidate; Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; Date: Sun, 29 Dec 2024 19:06:55 GMT; Server: openresty; Pragma: no-cache; X-Content-Type-Options: nosniff; Referrer-Policy: origin | body: {"status":"SUCCESS","cloudflare":"enabled","records":[{"id":"XXX","name":"root.domain","type":"A","content":"XXX.XXX.XXX.XXX","ttl":"600","prio":"0","notes":null}]} ``` the A record here has a value of "XXX.XXX.XXX.XXX" Then, if that value it got from the DNS lookup isn't correct, it will create or update the record, but it _doesn't_ validate that porkbun is already set to the correct value. Because the correct value already is set on the record, you're going to get that error. That being said, this should be a transient only issue and as soon as the DNS records properly propagate, it should stop trying to update the record and won't show any more failures. So my guess here, is that this is mostly just a transient "I just setup DDNS updater, and maybe setup a test IP prior to letting DDNS setup the DNS" issue vs a long-running issue. does that sound correct? I think I had proposed code to do an additional validation check to ensure we don't call update if the value is already correct, but ultimately that shouldn't be necessary, though it likely is what presents this somewhat confusing error case. You can see the logic [here](https://github.com/qdm12/ddns-updater/blob/master/internal/provider/providers/porkbun/provider.go#L143) So if we just change that to: ``` for _, record := range records { if record.Content != ipStr { err = p.updateRecord(ctx, client, recordType, p.owner, ipStr, record.ID) if err != nil { return netip.Addr{}, fmt.Errorf("updating record: %w", err) } } } ``` I believe that would resolve this transient issue, but then it would mask the issue that _some_ dns server has the wrong record value for your domain because the propagation hasn't happened yet. So I think it's better to have a transient error than to hide that error-case given that it _should_ resolve itself once the new DNS record finishes propagating.
saavagebueno commented 2025-11-20 04:24:28 -05:00
Author
Owner
Copy Link

@mmarszal commented on GitHub (Jan 10, 2025):

Hi bentemple,

Thanks for looking into the issue. Now that you mention transient dns, I wonder if it has to do with my local dns server using optimistic caching. I wonder if ddns-updater is resolving the old ip address. This issue is still on going for me, and my IP just updated a few hours ago, with all my domains updating, but then showing the error 5 minutes later as it still sees the old ip. Here is snippet of the logs:

2025-01-10T02:44:35Z INFO ipv4 address of root.domain is XXX.XXX.XXX.OLD and your ipv4 address is XXX.XXX.XXX.NEW
2025-01-10T02:44:40Z INFO Updating record [domain: root.domain | owner: @ | provider: porkbun | ip: ipv4] to use 87.123.147.244
2025-01-10T02:44:40Z DEBUG POST https://api.porkbun.com/api/json/v3/dns/retrieveByNameType/root.domain/A/ | headers: User-Agent: DDNS-Updater quentin.mcgaw@gmail.com; Content-Type: application/json; Accept: application/json | body: {"secretapikey":"sk1_XXX","apikey":"pk1_XXX"}
2025-01-10T02:44:41Z DEBUG 200 OK | headers: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; Referrer-Policy: origin; Date: Fri, 10 Jan 2025 02:44:41 GMT; Server: openresty; Set-Cookie: BUNSESSION2=XXX; path=/; secure; HttpOnly; SameSite=Lax; Expires: Thu, 19 Nov 1981 08:52:00 GMT; Pragma: no-cache; Content-Language: en-US, en; Content-Type: application/json; Cache-Control: no-store, no-cache, must-revalidate; X-Frame-Options: sameorigin; X-Content-Type-Options: nosniff; X-Xss-Protection: 1; mode=block | body: {"status":"SUCCESS","cloudflare":"enabled","records":[{"id":"XXX","name":"root.domain","type":"A","content":"XXX.XXX.XXX.OLD","ttl":"600","prio":"0","notes":null}]}
2025-01-10T02:44:41Z DEBUG POST https://api.porkbun.com/api/json/v3/dns/edit/root.domain/XXX | headers: User-Agent: DDNS-Updater quentin.mcgaw@gmail.com; Content-Type: application/json; Accept: application/json | body: {"secretapikey":"sk1_XXX","apikey":"pk1_XXX","content":"XXX.XXX.XXX.NEW","type":"A","ttl":"0","name":"@"}
2025-01-10T02:44:42Z DEBUG 200 OK | headers: Content-Type: application/json; Server: openresty; Expires: Thu, 19 Nov 1981 08:52:00 GMT; Cache-Control: no-store, no-cache, must-revalidate; X-Xss-Protection: 1; mode=block; Content-Language: en-US, en; Referrer-Policy: origin; Date: Fri, 10 Jan 2025 02:44:42 GMT; Set-Cookie: BUNSESSION2=XXX; path=/; secure; HttpOnly; SameSite=Lax; Pragma: no-cache; Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; X-Frame-Options: sameorigin; X-Content-Type-Options: nosniff | body: {"status":"SUCCESS"}

Then 5 minutes later

2025-01-10T02:54:35Z INFO ipv4 address of root.domain is XXX.XXX.XXX.OLD and your ipv4 address is XXX.XXX.XXX.NEW
(Then same error chain as in original post)

It's only about 10 minutes later from the last error that ddns updater sees the new ip

2025-01-10T03:04:35Z DEBUG ipv4 address of root.domain is XXX.XXX.XXX.NEW and your ipv4 address is XXX.XXX.XXX.NEW, skipping update
@mmarszal commented on GitHub (Jan 10, 2025): Hi bentemple, Thanks for looking into the issue. Now that you mention transient dns, I wonder if it has to do with my local dns server using optimistic caching. I wonder if ddns-updater is resolving the old ip address. This issue is still on going for me, and my IP just updated a few hours ago, with all my domains updating, but then showing the error 5 minutes later as it still sees the old ip. Here is snippet of the logs: ``` 2025-01-10T02:44:35Z INFO ipv4 address of root.domain is XXX.XXX.XXX.OLD and your ipv4 address is XXX.XXX.XXX.NEW 2025-01-10T02:44:40Z INFO Updating record [domain: root.domain | owner: @ | provider: porkbun | ip: ipv4] to use 87.123.147.244 2025-01-10T02:44:40Z DEBUG POST https://api.porkbun.com/api/json/v3/dns/retrieveByNameType/root.domain/A/ | headers: User-Agent: DDNS-Updater quentin.mcgaw@gmail.com; Content-Type: application/json; Accept: application/json | body: {"secretapikey":"sk1_XXX","apikey":"pk1_XXX"} 2025-01-10T02:44:41Z DEBUG 200 OK | headers: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; Referrer-Policy: origin; Date: Fri, 10 Jan 2025 02:44:41 GMT; Server: openresty; Set-Cookie: BUNSESSION2=XXX; path=/; secure; HttpOnly; SameSite=Lax; Expires: Thu, 19 Nov 1981 08:52:00 GMT; Pragma: no-cache; Content-Language: en-US, en; Content-Type: application/json; Cache-Control: no-store, no-cache, must-revalidate; X-Frame-Options: sameorigin; X-Content-Type-Options: nosniff; X-Xss-Protection: 1; mode=block | body: {"status":"SUCCESS","cloudflare":"enabled","records":[{"id":"XXX","name":"root.domain","type":"A","content":"XXX.XXX.XXX.OLD","ttl":"600","prio":"0","notes":null}]} 2025-01-10T02:44:41Z DEBUG POST https://api.porkbun.com/api/json/v3/dns/edit/root.domain/XXX | headers: User-Agent: DDNS-Updater quentin.mcgaw@gmail.com; Content-Type: application/json; Accept: application/json | body: {"secretapikey":"sk1_XXX","apikey":"pk1_XXX","content":"XXX.XXX.XXX.NEW","type":"A","ttl":"0","name":"@"} 2025-01-10T02:44:42Z DEBUG 200 OK | headers: Content-Type: application/json; Server: openresty; Expires: Thu, 19 Nov 1981 08:52:00 GMT; Cache-Control: no-store, no-cache, must-revalidate; X-Xss-Protection: 1; mode=block; Content-Language: en-US, en; Referrer-Policy: origin; Date: Fri, 10 Jan 2025 02:44:42 GMT; Set-Cookie: BUNSESSION2=XXX; path=/; secure; HttpOnly; SameSite=Lax; Pragma: no-cache; Strict-Transport-Security: max-age=63072000; includeSubDomains; preload; X-Frame-Options: sameorigin; X-Content-Type-Options: nosniff | body: {"status":"SUCCESS"} ``` Then 5 minutes later ``` 2025-01-10T02:54:35Z INFO ipv4 address of root.domain is XXX.XXX.XXX.OLD and your ipv4 address is XXX.XXX.XXX.NEW (Then same error chain as in original post) ``` It's only about 10 minutes later from the last error that ddns updater sees the new ip ``` 2025-01-10T03:04:35Z DEBUG ipv4 address of root.domain is XXX.XXX.XXX.NEW and your ipv4 address is XXX.XXX.XXX.NEW, skipping update ```
saavagebueno commented 2025-11-20 04:24:28 -05:00
Author
Owner
Copy Link

@bentemple commented on GitHub (Jan 14, 2025):

So I agree, this sounds like a local DNS cache look-up error.

Let's walk through the code:

  1. Within the update, grab the latest IP
  2. Use resolver to do actual lookup
  3. Default look-up ip for the resolver?
  4. https://cs.opensource.google/go/go/+/refs/tags/go1.23.4:src/net/lookup.go;l=128

So, that's your router's DNS, so if it's caching it for longer than the default cool-down, it would I believe cause this.

Probably 3 ways you could fix this. Set a specific DNS RESOLVER_ADDRESS to do the look-up not using your local router's DNS, extend the cool-down PERIOD to be longer than 5m, or just update your router's DNS to cache for a shorter period of time.

(Env variables for these settings)

@bentemple commented on GitHub (Jan 14, 2025): So I agree, this sounds like a local DNS cache look-up error. Let's walk through the code: 1. Within the update, [grab the latest IP](https://github.com/qdm12/ddns-updater/blob/master/internal/update/service.go#L198) 2. [Use resolver to do actual lookup](https://github.com/qdm12/ddns-updater/blob/master/internal/update/service.go#L69) 3. [Default look-up ip](https://github.com/qdm12/ddns-updater/blob/master/internal/resolver/resolver.go#L17C14-L17C29) for the resolver? 4. https://cs.opensource.google/go/go/+/refs/tags/go1.23.4:src/net/lookup.go;l=128 So, that's your router's DNS, so if it's caching it for longer than the [default cool-down](https://github.com/qdm12/ddns-updater/blob/master/internal/config/update.go#L20), it would I believe cause this. Probably 3 ways you could fix this. Set a specific DNS **RESOLVER_ADDRESS** to do the look-up not using your local router's DNS, extend the cool-down **PERIOD** to be longer than 5m, or just update your router's DNS to cache for a shorter period of time. ([Env](https://github.com/qdm12/ddns-updater/tree/master?tab=readme-ov-file#environment-variables) variables for these settings)
saavagebueno commented 2025-11-20 04:24:28 -05:00
Author
Owner
Copy Link

@mmarszal commented on GitHub (Jan 14, 2025):

Thanks for the detailed explanation. I will try to use a specific address for resolving the DNS.
I will observe the changes over the next few days to see what happens once my IP changes.

I guess what was really perplexing me, was that my other domains using NameCheap never had this problem. But now that I think about it, the NameCheap api probably accepts updating a domains IP to one that is already in use, while PorkBun treats this as an error.

I will update the issue after testing this out when the IP changes. Thanks again for looking into this and helping diagnose this.

@mmarszal commented on GitHub (Jan 14, 2025): Thanks for the detailed explanation. I will try to use a specific address for resolving the DNS. I will observe the changes over the next few days to see what happens once my IP changes. I guess what was really perplexing me, was that my other domains using NameCheap never had this problem. But now that I think about it, the NameCheap api probably accepts updating a domains IP to one that is already in use, while PorkBun treats this as an error. I will update the issue after testing this out when the IP changes. Thanks again for looking into this and helping diagnose this.
saavagebueno commented 2025-11-20 04:24:28 -05:00
Author
Owner
Copy Link

@mmarszal commented on GitHub (Jan 18, 2025):

Hi again,

I think we can close the issue now. I setup the container to use an external dns server as the resolver as per your suggestion, and over the last 2 days, my domains IP addresses were able to be updated multiple times without a single issue. It really does look like it was just a caching issue from my local DNS server.

Thanks again for the help with finding the root cause of the issue!

@mmarszal commented on GitHub (Jan 18, 2025): Hi again, I think we can close the issue now. I setup the container to use an external dns server as the resolver as per your suggestion, and over the last 2 days, my domains IP addresses were able to be updated multiple times without a single issue. It really does look like it was just a caching issue from my local DNS server. Thanks again for the help with finding the root cause of the issue!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Category: Config problem 📝
Category: Database 🗃️
Category: Documentation ✒️
Category: Foolproof settings 👼
Category: Good idea 🎯
Category: Healthcheck 🩺
Category: IP fetching 📥
Category: Label missing ❗
Category: Maintenance ⛓️
Category: Motivated! 🙌
Category: New provider 🆕
Category: Provider update ♻️
Category: Shoutrrr 📢
Category: Web UI 🖱️
Category: Wildcard 🃏
Closed: ⚰️ Inactive
Closed: 👥 Duplicate
Closed: 🗑️ Bad issue
Complexity: ☣️ Hard to do
Complexity: 🟩 Easy to do
Priority: 💤 Low priority
Priority: 🚨 Urgent
pull-request
Mirrored from GitHub Pull Request
 Status: 🔒 After next release
Status: 🔴 Blocked
Status: 🗯️ Waiting for feedback
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ddns-updater#479
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?