May 15 2013
Dyn SLA Update – or, How To Lose Friends and Alienate Customers
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.
Stuart
20th May 2013 @ 2:13 pm
Oops…
When I pasted the link above, I somehow forgot to remove my credentials from the script!
I’ve now performed a password-reset, but could anyone who retrieved the above script please edit/delete their copy? If nothing else, it shouldn’t authenticate any longer 😉
Many thanks,
Stuart
silverdulcet
20th May 2013 @ 9:06 pm
Just tried the script and I get Login Failed every time. Not sure what the problem is. Perhaps they’ve already made a change to their site?
Stuart
21st May 2013 @ 12:06 am
@silverdulcet (After updating my credentials) – it still looks good to me…
fermulator
21st May 2013 @ 5:57 am
Still working for me:
Martin
21st May 2013 @ 10:48 am
@silverdulcet
I hope you are not trying to authenticate with 😛
silverdulcet
21st May 2013 @ 12:05 pm
Nope. I filled in the proper credentials. Tried it with 2 different accounts. One password has special characters & one doesn’t.
boo
21st May 2013 @ 1:28 pm
Great script, will be running it as a cronjob on my NAS.
The only thing I had to change was the grep “-m 1” parameter. My system spits out a “grep: invalid option -- m” when using it.
Instead I used “head -n 1“, example:
yaztromo
21st May 2013 @ 4:34 pm
Thank you for this. It is working fine for me.
The only weakness I see is that it will be easy for Dyn to break the script, and they will probably do just that as often as possible.
Peterkneter
21st May 2013 @ 5:35 pm
It doesn’t work for me. I Always get 302 Found.
Here my Debug Information:
Ruediger
21st May 2013 @ 10:48 pm
I have tried with 3 accounts. One is working fine, the other two fail. Manual login works fine for all three accounts. None of the credentials contains special characters. The only difference of the failing one is a much longer login name. Might be a coincidence, but this is the only obvious difference…
Sean
22nd May 2013 @ 8:44 pm
I experience the same thing, using the proper credentials. It’s a great idea, and I’m much appreciative for the script, if I can figure out what’s going wrong.