Banned / Rate limited due to local DNS? #153

New Issue

saavagebueno · 2025-11-20T04:21:00-05:00

saavagebueno commented

2025-11-20 04:21:00 -05:00

Originally created by @Saxfusion on GitHub (Nov 19, 2021).

Once the basics were done i could spun up a container just fine.

One dynDNS service i use e.g. is Strato.

For IPv4/IPv6 usage i just put double entries into the config file.
e.g.

    {
      "provider": "strato",
      "domain": "sub.example.com",
      "host": "@",
      "password": "dyn-update-pwd",
      "ip_version": "ipv4",
      "provider_ip": false
    },
    {
      "provider": "strato",
      "domain": "sub.example.com",
      "host": "@",
      "password": "dyn-update-pwd",
      "ip_version": "ipv6",
      "provider_ip": false
    }

Seemed to work fine at first until i saw 5min updates of the IPs e.g. at dynv6.com. Strato being one that takes this harder and blocks you.

Little later i saw the following within the container log:

2021/11/19 14:14:24 INFO IPv4 address of sub.example.com is 192.168.x.y and your IPv4 address is 37.x.y.z
2021/11/19 14:14:24 INFO IPv6 address of sub.example.com is fe80::205:b:c:d and your IPv6 address is 2a02:8071:f:b:c:d:e:f
2021/11/19 14:14:24 INFO Updating record [domain: sub.example.com \| host: @ \| provider: Strato] to use 37.x.y.z
2021/11/19 14:14:25 ERROR sub.example.com: banned due to abuse, no more updates will be attempted for an hour
2021/11/19 14:14:25 INFO Updating record [domain: sub.example.com \| host: @ \| provider: Strato] to use 2a02:8071:f:b:c:d:e:f
2021/11/19 14:14:25 ERROR sub.example.com: banned due to abuse, no more updates will be attempted for an hour

So somehow the local DNS Server (Split-DNS) disturbs the container in thinking that there always is a miss-match with the also correctly found public IPs and updating the A/AAAA records every 5 minutes. Seems the comparison before / after for the public IPs only is not working as intended anymore in that case.

Is there any way besides e.g. the cooldown variable to work around this?
If possible i would like to circumvent using this variable since some IPs change hourly / daily and others only every few months.
And only updating the A/AAAA records if really necessary would be nice.

Edit:
If i use other methods, e.g. https://dynv6.com/docs/apis on a linux server, or e.g. DDNS updater 2 on a Synology DSM 6, everything is working as expected. They are not bothered by the local DNS and only update records on IP changes.

Originally created by @Saxfusion on GitHub (Nov 19, 2021). Once the basics were done i could spun up a container just fine. One dynDNS service i use e.g. is Strato. For IPv4/IPv6 usage i just put double entries into the config file. e.g. ```json { "provider": "strato", "domain": "sub.example.com", "host": "@", "password": "dyn-update-pwd", "ip_version": "ipv4", "provider_ip": false }, { "provider": "strato", "domain": "sub.example.com", "host": "@", "password": "dyn-update-pwd", "ip_version": "ipv6", "provider_ip": false } ``` Seemed to work fine at first until i saw 5min updates of the IPs e.g. at dynv6.com. Strato being one that takes this harder and blocks you. Little later i saw the following within the container log: ``` 2021/11/19 14:14:24 INFO IPv4 address of sub.example.com is 192.168.x.y and your IPv4 address is 37.x.y.z 2021/11/19 14:14:24 INFO IPv6 address of sub.example.com is fe80::205:b:c:d and your IPv6 address is 2a02:8071:f:b:c:d:e:f 2021/11/19 14:14:24 INFO Updating record [domain: sub.example.com \| host: @ \| provider: Strato] to use 37.x.y.z 2021/11/19 14:14:25 ERROR sub.example.com: banned due to abuse, no more updates will be attempted for an hour 2021/11/19 14:14:25 INFO Updating record [domain: sub.example.com \| host: @ \| provider: Strato] to use 2a02:8071:f:b:c:d:e:f 2021/11/19 14:14:25 ERROR sub.example.com: banned due to abuse, no more updates will be attempted for an hour ``` So somehow the local DNS Server (Split-DNS) disturbs the container in thinking that there always is a miss-match with the also correctly found public IPs and updating the A/AAAA records every 5 minutes. Seems the comparison before / after for the public IPs only is not working as intended anymore in that case. Is there any way besides e.g. the cooldown variable to work around this? If possible i would like to circumvent using this variable since some IPs change hourly / daily and others only every few months. And only updating the A/AAAA records if really necessary would be nice. Edit: If i use other methods, e.g. https://dynv6.com/docs/apis on a linux server, or e.g. DDNS updater 2 on a Synology DSM 6, everything is working as expected. They are not bothered by the local DNS and only update records on IP changes.

saavagebueno closed this issue

2025-11-20 04:21:00 -05:00

saavagebueno commented

2025-11-20 04:21:00 -05:00

@qdm12 commented on GitHub (Nov 22, 2021):

What DNS server are you running? Why would it be different for strato?

The program is designed to DNS resolve your domain and compare it with your public IP address. How would you want to work around this? 🤔

@qdm12 commented on GitHub (Nov 22, 2021): What DNS server are you running? Why would it be different for strato? The program is designed to DNS resolve your domain and compare it with your public IP address. How would you want to work around this? :thinking:

saavagebueno commented

2025-11-20 04:21:00 -05:00

@Saxfusion commented on GitHub (Nov 23, 2021):

I apologize. That might have been misleading and not completely accurate.

One case is pihole as DNS resolver + unbound, on another site it is Adguard as a resolver.

The problem is not specific to Strato but to Domains that get resolved internally. E.g. For sub.example.com the result will be 192.168.178.x when queried at the local resolver, but 37.46.x.y when an external resolver is questioned.

So I would assume that somehow the internal proceedings are different which leads to 'ddns updater 2' doing nothing while the ddns-updater here feels compelled to update it every 5 minutes. Both running within the same LAN (not at the same time) facing the same local resolvers.
Maybe 'ddns updater 2' is only evaluating external resolvers, or only checking the results of the ip check for changes and ignoring DNS results.

The public IP check obviously works just fine.
Can I somhow force the use of external dns resolvers only which presumably would 'fix' the comparison of dns-query VS IP-check constantly resulting in 'new ip found, updating'?

@Saxfusion commented on GitHub (Nov 23, 2021): I apologize. That might have been misleading and not completely accurate. One case is pihole as DNS resolver + unbound, on another site it is Adguard as a resolver. The problem is not specific to Strato but to Domains that get resolved internally. E.g. For sub.example.com the result will be 192.168.178.x when queried at the local resolver, but 37.46.x.y when an external resolver is questioned. So I would assume that somehow the internal proceedings are different which leads to 'ddns updater 2' doing nothing while the ddns-updater here feels compelled to update it every 5 minutes. Both running within the same LAN (not at the same time) facing the same local resolvers. Maybe 'ddns updater 2' is only evaluating external resolvers, or only checking the results of the ip check for changes and ignoring DNS results. The public IP check obviously works just fine. Can I somhow force the use of external dns resolvers only which presumably would 'fix' the comparison of dns-query VS IP-check constantly resulting in 'new ip found, updating'?

saavagebueno commented

2025-11-20 04:21:01 -05:00

@qdm12 commented on GitHub (Nov 23, 2021):

Ah ok! I had the same problem. What I do is that I use a separate DNS container (https://github.com/qdm12/dns/tree/v2.0.0-beta) for DDNS updater. A simpler fix is to add something like

dns:
  - 1.1.1.1

to your docker-compose.yml (or use --dns 1.1.1.1 for docker run)

@qdm12 commented on GitHub (Nov 23, 2021): Ah ok! I had the same problem. What I do is that I use a separate DNS container (https://github.com/qdm12/dns/tree/v2.0.0-beta) for DDNS updater. A simpler fix is to add something like ```yml dns: - 1.1.1.1 ``` to your docker-compose.yml (or use `--dns 1.1.1.1` for `docker run`)

saavagebueno commented

2025-11-20 04:21:01 -05:00

@Saxfusion commented on GitHub (Nov 23, 2021):

That's an idea. Why couldn't I think outside the box/container. 😂
Gonna have to open the firewall a little (currently squashed all dns traffic to the local resolver, besides DoH which is more tricky), but that is worth it then.
Going to try it on the weekend I guess.

@Saxfusion commented on GitHub (Nov 23, 2021): That's an idea. Why couldn't I think outside the box/container. 😂 Gonna have to open the firewall a little (currently squashed all dns traffic to the local resolver, besides DoH which is more tricky), but that is worth it then. Going to try it on the weekend I guess.

saavagebueno commented

2025-11-20 04:21:01 -05:00

@qdm12 commented on GitHub (Nov 24, 2021):

Yeah I myself had to fiddle with my Docker firewall table 😄
If you want I can add an option to use a different DNS from within the container, let me know (although you'll still have to change your firewall).

@qdm12 commented on GitHub (Nov 24, 2021): Yeah I myself had to fiddle with my Docker firewall table :smile: If you want I can add an option to use a different DNS from within the container, let me know (although you'll still have to change your firewall).

saavagebueno commented

2025-11-20 04:21:01 -05:00

@Saxfusion commented on GitHub (Nov 24, 2021):

As long as I can get it running via docker-compose, fine by me.
I just used the click-Syno-GUI for the first test and didn't bother... But in the end I try to always use docker-compose. Just keeps it more flexible in where I run the container later on.

@Saxfusion commented on GitHub (Nov 24, 2021): As long as I can get it running via docker-compose, fine by me. I just used the click-Syno-GUI for the first test and didn't bother... But in the end I try to always use docker-compose. Just keeps it more flexible in where I run the container later on.

saavagebueno commented

2025-11-20 04:21:01 -05:00

@Saxfusion commented on GitHub (Dec 4, 2021):

Docker compose running on one system with the fixed external DNS assignment.
Will try it within the next 2 days on the system where i had experienced more problems on the trial.
If that is successful we can close this issue afterwards

@Saxfusion commented on GitHub (Dec 4, 2021): Docker compose running on one system with the fixed external DNS assignment. Will try it within the next 2 days on the system where i had experienced more problems on the trial. If that is successful we can close this issue afterwards

saavagebueno commented

2025-11-20 04:21:01 -05:00

@Saxfusion commented on GitHub (Dec 6, 2021):

Fixed DNS for the container via docker-compose running on 3 homes now.
Gonna keep watch over the week. Got some < nil > IP detections resulting in repetitive updates. But i had no time to look at it so far. But that might be better suited in the spdyn or another thread then.

@Saxfusion commented on GitHub (Dec 6, 2021): Fixed DNS for the container via docker-compose running on 3 homes now. Gonna keep watch over the week. Got some < nil > IP detections resulting in repetitive updates. But i had no time to look at it so far. But that might be better suited in the spdyn or another thread then.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ddns-updater#153