DynDNS blocking for abuse after 6.306 update

Hi all,
 
I guess you are using static ip's.
 
The default setting in ASL 6 for the maximum time interval between updates of an _unchangend_ ip is one day.
That worked well for many years.
 
But now DynDns enforces its policy that says its an abuse to update a static ip more often then every 28 days. So I guess just unblocking your dyndns account is no longterm solution. [:)]
 
So if you have a static ip _or_ your ip doesn't change very frequently, you should go to
/etc/dyndns.conf-default, change the "max-interval" to 2419200 (28 days) and do a "dyndns reload".
 
Please note that the max-interval only is used for unchanged ip's. When you get a new ip, the dyndns entry is updated immediatly.
 
Kind Regards,
 
Daniel

So if you have a static ip _or_ your ip doesn't change very frequently, you should go to /etc/dyndns.conf-default, change the "max-interval" to 2419200 (28 days) and do a "dyndns reload".

After editing /etc/dyndns.conf-default, it is not enough to reload dyndns because /var/mdw/scripts/dyndns just reads /etc/dyndns.conf without regenerating it from the -default template.  To regenerate /etc/dyndns.conf
after editing /etc/dyndns.conf-default, you must restart the MiddleWare.  Restarting the MiddleWare will also reload dyndns, so you do not need to do that manually.

So if you have a static ip _or_ your ip doesn't change very frequently, you should go to /etc/dyndns.conf-default, change the "max-interval" to 2419200 (28 days) and do a "dyndns reload".

After editing /etc/dyndns.conf-default, it is not enough to reload dyndns because /var/mdw/scripts/dyndns just reads /etc/dyndns.conf without regenerating it from the -default template.  To regenerate /etc/dyndns.conf
after editing /etc/dyndns.conf-default, you must restart the MiddleWare.  Restarting the MiddleWare will also reload dyndns, so you do not need to do that manually.

Some thoughts...

First, if one has a static IP, then it is not necessary to run updates against DynDNS anyway. Just configure an A record for your public interface and be done with it. There is no timeout issue at all; DynDNS does *not* expire static IP's (I suppose perhaps with the non-custom setup; but I am talking about "real" DNS services...).

Next, reload (or restart) completely stops ez-ipupdate and starts it. If one has applied the hack per my initial statement (changing the conf from dyndns.conf to ez-ipupdate.conf), the middleware really has nothing to do with the procedure.

Here is the start/stop script for dyndns:

#! /bin/sh
#
#  Copyright (C) 2000-2004 Astaro AG
#  For copyright information look at /doc/astaro-license.txt
#  or http://www.astaro.com/doc/astaro-license.txt
#
# $Id: dyndns,v 1.7 2005/05/27 15:09:24 daniel Exp $
#

return=0

PROG="/usr/bin/ez-ipupdate"
ARGS=" -c /etc/ez-ipupdate.conf"
NOSELFM="/etc/no-selfmonitor/dyndns"
PNAME="Ez-IPupdate"

case "$1" in
        start)
        echo -n "Starting $PNAME:"
        killall -9 $PROG > /dev/null 2>&1
        $PROG $ARGS || return=1
        rm -f $NOSELFM
        logger -p user.info -t ez-ipupdate "$PNAME started."
        echo -e "$return"
;;
        stop)
        echo -n "Shutting down $PNAME:"
        touch $NOSELFM
        killall -9 $PROG 2> /dev/null || return=1
        logger -p user.info -t ez-ipupdate "$PNAME stopped."
        echo -e "$return"
;;
        restart|reload)
        $0 stop || return=1
        sleep 1;
        $0 start || return=1
;;
*)
echo "Usage: $0 {start|stop|restart|reload}"
exit 1
;;
esac

exit $return

(Note the ARGS  parameter at the top.)

If using the hack I mentioned previously, the edit would go into ez-ipupdate.conf, and the middleware is not involved. There is also (currently) no chance of the default  configuration overwriting the adjusted settings.

Your observation, is correct, of course: merely editing dyndns.conf-default without restarting the middleware would result in dyndns.conf not being updated, and merely restarting ez-ipupdate with the existing settings.

The danger of modifying dyndns.conf-default is that it is quite possible that an update from Astaro may overwrite it and nullify any changes made, which is why  theRat's hack is so elegant.