search

troglobit / inadyn

In-a-Dyn is a dynamic DNS client with multiple SSL/TLS library support
https://troglobit.com/projects/inadyn/
GNU General Public License v2.0
919 stars 139 forks source link

429s towards noip.com #238

Open milanaleksic opened 5 years ago

milanaleksic commented 5 years ago

I have a problem with updates to noip.com that have started today, here is the log:

Sat Mar  2 18:17:03 2019: Inadyn version 1.99.4 -- Dynamic DNS update client.
Sat Mar  2 18:17:03 2019: Resolving hostname admin-sol.<HOSTNAME>.net => IP# 192.168.1.115                                                                             
Sat Mar  2 18:17:03 2019: Checking for IP# change, connecting to ip1.dynupdate.no-ip.com(35.169.225.84)                                                                  
Sat Mar  2 18:17:03 2019: Update needed for alias h1.<HOSTNAME>.net, new IP# <IP>                                                                    
Sat Mar  2 18:17:03 2019: Update needed for alias h2.<HOSTNAME>.net, new IP# <IP>                                                                        
Sat Mar  2 18:17:03 2019: Update needed for alias h3.<HOSTNAME>.net, new IP# <IP>                                                                         
Sat Mar  2 18:17:03 2019: Update needed for alias h4.<HOSTNAME>.net, new IP# <IP>                                                                          
Sat Mar  2 18:17:03 2019: Update needed for alias h5.<HOSTNAME>.net, new IP# <IP>                                                                           
Sat Mar  2 18:17:03 2019: Update needed for alias h6.<HOSTNAME>.net, new IP# <IP>                                                                         
Sat Mar  2 18:17:03 2019: Update needed for alias h7.<HOSTNAME>.net, new IP# <IP>                                                                        
Sat Mar  2 18:17:03 2019: Update needed for alias h8.<HOSTNAME>.net, new IP# <IP>                                                                          
Sat Mar  2 18:17:03 2019: Update needed for alias h9.<HOSTNAME>.net, new IP# <IP>                                                                       
Sat Mar  2 18:17:03 2019: Update needed for alias h10.<HOSTNAME>.net, new IP# <IP>                                                                         
Sat Mar  2 18:17:04 2019: Sending IP# update to DDNS server, connecting to dynupdate.no-ip.com(8.23.224.120)                                                             
Sat Mar  2 18:17:04 2019: Successful alias table update for h1.<HOSTNAME>.net => new IP# <IP>                                                        
Sat Mar  2 18:17:05 2019: Sending IP# update to DDNS server, connecting to dynupdate.no-ip.com(8.23.224.120)                                                             
Sat Mar  2 18:17:05 2019: Successful alias table update for h2.<HOSTNAME>.net => new IP# <IP>                                                            
Sat Mar  2 18:17:06 2019: Sending IP# update to DDNS server, connecting to dynupdate.no-ip.com(8.23.224.120)                                                             
Sat Mar  2 18:17:07 2019: Successful alias table update for h3.<HOSTNAME>.net => new IP# <IP>                                                             
Sat Mar  2 18:17:08 2019: Sending IP# update to DDNS server, connecting to dynupdate.no-ip.com(8.23.224.120)                                                             
Sat Mar  2 18:17:09 2019: Successful alias table update for h4.<HOSTNAME>.net => new IP# <IP>                                                              
Sat Mar  2 18:17:10 2019: Sending IP# update to DDNS server, connecting to dynupdate.no-ip.com(8.23.224.120)                                                             
Sat Mar  2 18:17:10 2019: Successful alias table update for h5.<HOSTNAME>.net => new IP# <IP>                                                               
Sat Mar  2 18:17:11 2019: Sending IP# update to DDNS server, connecting to dynupdate.no-ip.com(8.23.224.120)                                                             
Sat Mar  2 18:17:11 2019: Successful alias table update for h6.<HOSTNAME>.net => new IP# <IP>                                                             
Sat Mar  2 18:17:12 2019: Sending IP# update to DDNS server, connecting to dynupdate.no-ip.com(8.23.224.120)                                                             
Sat Mar  2 18:17:12 2019: Fatal error in DDNS server response:
Sat Mar  2 18:17:12 2019: [429 Too Many Requests]
Sat Mar  2 18:17:12 2019: Error response from DDNS server, exiting!
Sat Mar  2 18:17:12 2019: Failed starting daemon: RC_DYNDNS_RSP_NOTOK

So, I have a question: usually "throttling" 429s responses are avoided/fixed/remedied by introducing retries with exponential random backoff. Is there a way to schedule this feature into inadyn, pretty please?

Thanks!

troglobit commented 5 years ago

Two things:

  1. Have you tried the latest version of Inadyn instead of that six year old version?
  2. Some providers, like FreeDNS, support linked updates which update multiple records at the same time, have you looked into that for noip?

Now, we still don't have exponential backoff, and even if we did, this issue you bring up is more of a limitation on the DDNS provider, so any workarounds should be done in that plugin. You're welcome to contribute.

milanaleksic commented 5 years ago

Hi,

Thanks for your comments. Indeed it is an older version but the all of my nodes are debian jessie arm servers, not rpi which I could easily upgrade but some other older types without the active support. I will look into upgrading and update the ticket if I find a way, but have 2 very small kids, not a lot of off-work GH commits happening here :(

I have reached out to the noip via a support ticket but so far they do not acknowledge that throttling 429s are an API breaking change (which I don’t really agree with) but that’s how things are done nowadays I guess.

Feel free to close the ticket if it becomes annoying, but please consider leaving it open in case someone appears who had time to fix the underlying issue in the provider code.

KR, Milan