Forced Update Improvement

[iAnomaly]

I'd love to see the Forced Update event set the IP to a random value and immediately set again to actual value. This circumvents silly free DDNS providers who do not consider an update with an unchanged IP address to actual be an update. Simply put, DDNS providers who expire free hosts addresses after an inactivity threshold punish users who's address remain constant for long periods of time and reward those who's change frequently.

[taem]

Any ideas which random IP should be generated?

[iAnomaly]

Is that a trick question? =P If I told you WHICH IP, it wouldn't be random.

Seriously though, the random IP doesn't matter because it should be IMMEDIATELY changed to the actual IP after. The only purpose is to trick the DDNS server into thinking the IP changed when in fact, it didn't.

Does this make sense?

Cheers

On May 17, 2012, at 1:03 AM, Timur Birshreply@reply.github.com wrote:

Any ideas which random IP should be generated?

---

Reply to this email directly or view it on GitHub:
#15 (comment)

[taem]

Hi,

Thursday 17 May 2012 20:18, Cameron Boulton:

Is that a trick question? =P If I told you WHICH IP, it wouldn't be random.

Sorry, my English is not very well.
I meant which kind of IP should be generated - private/public?

Seriously though, the random IP doesn't matter because it should be
IMMEDIATELY changed to the actual IP after. The only purpose is to trick
the DDNS server into thinking the IP changed when in fact, it didn't.

Does this make sense?

I guess.

Timur

[troglobit]

Interesting idea! We've had a few issues with customers not getting their records updated properly. This workaround could actually prove useful.

[iAnomaly]

Glad to hear. I recommend only performing this on a FORCED event, not every usual check for an IP change. DDNS providers could start banning users who abuse this feature. Another reason a "random" IP is important compared to 0.0.0.0

On May 20, 2012, at 3:13 PM, Joachim Nilssonreply@reply.github.com wrote:

Interesting idea! We've had a few issues with customers not getting their records updated properly. This workaround could actually prove useful.

---

Reply to this email directly or view it on GitHub:
#15 (comment)

[troglobit]

I shall see what I can do, but it is likely I will not have time to work on this until the fall.

As usual, patches are most welcome! :)

[troglobit]

This issue has been stuck a bit too long for my comfort. I've both been out of time and also out of clue on the random IP# as well as unclear on what DDNS service providers would appreciate a client that accesses too fast.

What about this?

1. Triggered by external event, SIGUSR1 and new config option: --fake-address-change
2. Send update to (all) DDNS provider(s) in .conf using random address from 203.0.113.0/24, RFC5737
3. Wait random number of seconds (1-10)
4. Send new update with actual IP address to (all) DDNS prover(s) in .conf