I today received an email from Dyn (previously DynDNS), stating:
Starting now, if you would like to maintain your free Dyn account, you must log into your account once a month. Failure to do so will result in expiration and loss of your hostname. Note that using an update client will no longer suffice for this monthly login.
(emphasis theirs)
Now, if this were a service which requires interaction then this would be an unfriendly but potentially fair way to weed-out inactive accounts. This isn’t one of those cases, though – I can happily go for months or even years where my only interaction with Dyn(DNS) is via auto-update clients. And this is the heart of the problem – many routers and embedded devices have built-in DynDNS clients, frequently with no option to switch to an alternative service. Possibly this is worth $25/year, possibly it isn’t. Personally, I’m not paying a penny to a company trying to hold its users to ransom like this. For my usage, there are a handful for hostnames in a Dyn(DNS) domain – and therefore these cannot to transferred to a different provider. I keep them going purely so that historic links will still work.
And, to resolve the immediate problem, I wrote this script which can be scheduled to run every 15 days in order to keep my account active – enjoy!
#!/bin/bash
LOGIN="****"
PASSWORD="****"
COOKIES="/tmp/.dynsdns.cookies.txt"
AL="en-gb"
#UA="Mozilla/5.0 (Macintosh; Intel Mac OS X) AppleWebKit/0.0.0 (KHTML, like Gecko) Version/0.0.0 Safari/0.0.0"
LOGINURL="https://account.dyn.com/entrance/"
POSTURL="$LOGINURL"
CHKURL="https://account.dyn.com/"
(( DEBUG )) && DST="-" || DST="/dev/null"
[[ -w "$( dirname "$COOKIES" )" ]] || { echo >&2 "FATAL: Cannot write to directory '$( dirname "$COOKIES" )'" ; exit 1; }
# Ensure no broken session caching...
if [[ -s "$COOKIES" ]]; then
[[ -w "$COOKIES" ]] || { echo >&2 "FATAL: Cannot write to file '$COOKIES'" ; exit 1 ; }
rm -f "$COOKIES" >/dev/null 2>&1
fi
(( DEBUG )) && echo >&2 "DEBUG: Fetching initial headers to pre-load cookies..."
curl -b $COOKIES -c $COOKIES -Ikso "$DST" -A "$UA" --url "$LOGINURL"
(( DEBUG )) && echo >&2 "DEBUG: Fetching UID..."
VALUE="$(
curl -b $COOKIES -c $COOKIES -kso - -A "$UA" --url "$LOGINURL" | \
grep -m 1 "multiform" | \
cut -d"'" -f 6
)"
(( DEBUG )) && echo >&2 "DEBUG: Read UID as '$VALUE' - posting data..."
curl -b $COOKIES -c $COOKIES -d "username=$LOGIN" -d "password=$PASSWORD" -d "iov_id" -d "multiform=$VALUE" -e "$LOGINURL" -kso "$DST" -A "$UA" --url "$POSTURL"
(( DEBUG )) && echo >&2 "DEBUG: Response received - verifying result..."
curl -b $COOKIES -c $COOKIES -e "$POSTURL" -kso - -A "$UA" -H "Accept-Language: $AL" --url "$CHKURL" | \
grep -qE "<span>(Welcome|Hi) <b>$LOGIN</b></span>" \
&& echo "Login successful" \
|| { echo >&2 "Login failed" ; exit 1 ; }
exit 0
Download this script from http://files.stuart.shelton.me/unix/dyndns-login.sh.
48 replies on “Dyn SLA Update – or, How To Lose Friends and Alienate Customers”
@silverdulcet You might need to change the double-quotes for single-quotes, e.g.:
… to make sure that nothing tries to interpret it. Dollar symbols especially could be problematic.
@boo: Your NAS could well be using busybox rather than GNU coreutils grep, in which case it may be lacking the ‘match <n> option – but using ‘head‘ is definitely a perfectly good work-around.
@yaztromo: … or they might just disable free accounts. That seems to be the way they’re headed.
Step 1: Make free accounts a pain to maintain;
Step 2: Point out the drop-off in the number of free accounts;
Step 3: Because clearly no-one wants a free account, cancel them;
Step 4: ???
Step 5: Profit!
@Peterkneter: ‘Found’ *is* the correct response at this stage – the final check is a dumb string-match against the accounts page. It could be that your accounts page is localised (e.g. not reading “Welcome”) or it could be that it your username ($LOGIN) is interesting and/or long that it has been truncated/altered.
@silverdulcet, @Ruediger: Thinking about it, this could be the issue affecting you too.
Could anyone with a language *not* set to en-GB or en-US please login manually and then look at the accounts page for the equivalent of “Welcome <username>” and post what they find here?
I see the DEBUG lines in the script. How would I enable them to see if I can find where the error is.
The usernames of the 2 accounts I tried are 9 and 12 characters, just regular letters no numbers or special characters. Language is set to en-US.
@silverdulcet:
@Stuart
used debug for successful account and failing one. Here only debug info:
———————————
———————–
———————–
——————-
I found my problem. I used my E-Mail address instead of the username. Now it is working fine.
@Stuart:
Where can I change the language at dyn.com?
To everyone who’s having problems:
It does look as if the authentication has actually been successful, but the check afterwards is failing.
To help to diagnose this, please update the final line of the original script to:
FILE="$( mktemp -t "$0.XXXXXXXX" )" || { echo >&2 "mktemp failed: $?" ; exit 1 ; } curl -b $COOKIES -c $COOKIES -e "$POSTURL" -kso - -A "$UA" --url "$CHKURL" -o "$FILE" if grep -q "<span>Welcome <b>$LOGIN</b></span>"; then echo "Login successful" else echo >&2 "Login failed" grep -q "<span>Welcome " "$FILE" && echo "Page contains 'welcome' string" grep -q "<b>$LOGIN</b>" "$FILE" && echo "Page contains username" PATTERN="<span>[^&]+ <b>[^<]+</b></span>" grep -Eq "$PATTERN" "$FILE" && echo "Page contains welcome pattern $( grep -Eo "$PATTERN" "$FILE" )" echo "Checks complete" fi rm "$FILE"@Peterkneter: D’oh!
I don’t actually know that you can change the language – it just struck me that if “Welcome” is localised then it might explain why people are having problems 😉