This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DynDNS blocking for abuse after 6.306 update

Has anyone else noticed the above? Three different clients of ours running ASL 6 (and one of our own networks) have been blocked for abuse. Perhaps it has something to do with our hack for multiple custom hosts (see https://community.sophos.com/products/unified-threat-management/astaroorg/f/51/t/18969, but I can't quite tell as yet.


This thread was automatically locked due to age.
Parents
  • 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.
  • 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.
Reply
  • 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.
Children
No Data