Melbourne IT - anyone have any contacts?

[Piers Rowan via luv-main]

Hi there,

Does anyone know someone in AU from here? I've got a massive problem because none
of their automated stuff works (account recovery, etc) and support can't do anything
until Monday.

I normally post from another account but it won't work because the expired domain
notice was send to an address that was changed and now the lights are out on the
DNS.

I wouldn't ask if it was important but if you can ping your networks I would be greatly
appreciative.

If you can't assist then pls forgive this intrusion into your weekend and have a
great day!

Thanks

Piers

[Rohan McLeod via luv-main]

Post by Piers Rowan via luv-main
Hi there,
Does anyone know someone in AU from here?

Well I certainly don't;
 but just to be clear for me and others, you normally seem to post from :
"***@recruitonline.com.au" and presumably that is hosted by :
https://www.melbourneit.com.au/contact-us/ ? ;
So you need a personal access to a "Melbourne IT" person;
preferably someone based in Melbourne ?

regards Rohan McLeod

[Andrew McGlashan via luv-main]

Hi,

Post by Piers Rowan via luv-main
Does anyone know someone in AU from here? I've got a massive problem because none
of their automated stuff works (account recovery, etc) and support can't do anything
until Monday.

Sorry I can't help, but I wouldn't recommend Melbourne.IT to ANYBODY,
not even my worst enemies if I had any. Same goes for Netregistry
(which they now own, btw.... but my view was the same before
Melbourne.IT acquired them).

Cheers
A.

[Piers Rowan via luv-main]

Post by Andrew McGlashan via luv-main
Sorry I can't help, but I wouldn't recommend Melbourne.IT to ANYBODY,

We have one domain with them (which my Dad bought in 2000) and there were two other sites under the same account. One of the other domain owners recovered their domain access and changed the notification email to something other than the company inbox.

I will be moving the domain in great haste to a viable provider.

I am back up now after 8 calls to the same off shore team who told me they couldn't access the account so someone would call me on Monday. NONE of their web recovery tools worked or even recognised my account or domain.

Perhaps it would be wrong to can a company on the Internet but:

1) Their social media chat was a bot
2) They can't run any sort of web services
3) They keep you on hold for 15 minutes and then the call drops (automated?)
4) They tell you that they can't do anything then after 7 calls the same coal face employee can achieve a task.

Thanks to those of you who replied; and apologies to those who got spammed this message.

Cheers

P

[Erik Christiansen via luv-main]

Post by Piers Rowan via luv-main
Thanks to those of you who replied; and apologies to those who got spammed this message.

Glad to hear that persistence worked for you, in the end.

A community needs a little list traffic now and then, and awareness of
the risks out there is valuable. (This thread added to two of my 1266
topic-specific mail archive folders.)

Erik

[Russell Coker via luv-main]

Post by Piers Rowan via luv-main
We have one domain with them (which my Dad bought in 2000) and there were
two other sites under the same account. One of the other domain owners
recovered their domain access and changed the notification email to
something other than the company inbox.
I will be moving the domain in great haste to a viable provider.

Does anyone know of a good way of monitoring this? I have experimented with
monitoring the output of the "whois" command, but they are quite aggressive
about blocking multiple connections from the same IP address.

All I want is a way of discovering when my domains will expire which doesn't
depend on receiving email from Melbourne IT or similar.

I have scripts monitoring the zones I am responsible for via lookups to
8.8.8.8 (Google DNS). That allows me to quickly organise payment when it's
forgotten (fast enough that many sites still have the entries in the cache by
the time it's fixed). But won't cover me for the case that Piers experienced
of finding out that a domain has expired but then being unable to immediately
renew it.

[Erik Christiansen via luv-main]

Post by Russell Coker via luv-main
All I want is a way of discovering when my domains will expire which doesn't
depend on receiving email from Melbourne IT or similar.

If payment is annual, then isn't it almost sufficient to use "calendar"
to email you a month in advance? (I have it reminding me each day for a
fortnight before important birthdays, so I have time to buy a card/gift)

If there are grounds for paranoia, then maybe run a lookup after 6,9,11
months, as back-up? Three per year shouldn't trigger much aggression?

Finding out after expiry is the bit that I don't understand. (OK, I've
just added car rego to ~/.calendar/calendar, as I'm liable if Vicroads
forget to send me a bill.)

Note: The file is like a makefile - don't let tabs be converted to
spaces. (I use a vim modeline for that.) Fortnight lookahead: -l 14

Erik

[Rick Moen via luv-main]

Post by Russell Coker via luv-main
Does anyone know of a good way of monitoring this? I have experimented with
monitoring the output of the "whois" command, but they are quite aggressive
about blocking multiple connections from the same IP address.

Yes, albeit some TLDs have uninformative whois output or other problems.

In http://linuxmafia.com/pub/linux/network/, you will find both
domain-check (various numbered versions thereof) and d-check. Both are
Perl scripts for this purpose. To this day, every Sunday I get e-mail
via a cron job that runs domain-check against a set of about three dozen
domains (mine, friends', and those of institutions I care about) to tell
me which of them are within 90 days of expiration (and if any are past
expiration).

You'll also find a shell script called domain-check.ryan, the
ur-implementation that started all this. (Master index for this
directory is the http://linuxmafia.com/pub/linux/network/00index.txt
file.)

In 2007, when I was contributing editor to _Linux Gazette_ (now defunct), I
wrote an article called 'Preventing Domain Expiration'[1], that talked
about the utility of running Ryan Matteson's 'domain-check' shell script
and being warned about pending expirations. Unfortunately, Ryan's work
didn't handle important TLDs (such as .org) and presented maintenance
difficulties, so Perl coder Ben Okopnik, with some help from me, wrote
Ben's replacement Perl implementation of domain-check, the one that is
present in many versions.

In the years since then, Ben has EOLed said code. It has now accumulated
a few problems, solely on account of new TLDs whose whois output it
cannot parse, or changed behaviour at incumbent TLDs. I checked with my
friend Jesse Monroy, who (FWIW) absolutely hated Ben's coding style, and
decided to write his own from-scratch Perl replacement, which is what d-check
is.

As I say in 00index.txt, Jesse's upstream repo is:
https://github.com/jessemonroy650/d-check

My various template, example, and cron script files, although tuned for
Ben's domain-check, may be of use and can be found in that same
directory.

Post by Russell Coker via luv-main
All I want is a way of discovering when my domains will expire which doesn't
depend on receiving email from Melbourne IT or similar.

Done. Yr. welcome.


[1] http://linuxmafia.com/~rick/preventing-expiration.html
Warning: Article talks mostly about _Ryan's_ domain-check, because Ben's
was just then newly written and a bit raw. However, please take care to
avoid Ryan's shell-script implementation of the idea, as it's a quite flawed
implementation compared to _both_ Ben's and Jesse's Perl versions.

[Rick Moen via luv-main]

To this day, every Sunday I get e-mail via a cron job that runs
domain-check against a set of about three dozen domains (mine,
friends', and those of institutions I care about) to tell me which of
them are within 90 days of expiration (and if any are past
expiration).

FYI, here's an example report sent using said cron job, that leverages
Ben Okopnik's 'domain-check' Perl script:


---<begin>---

Date: Sun, 24 Dec 2017 07:12:02 -0800
From ***@linuxmafia.com Sun Dec 24 07: 2:02 2017
From: root <***@linuxmafia.com>
To: ***@linuxmafia.com
Subject: domain-check: Domain expiration warning (90 day cutoff)

According to 'whois', these domains will expire soon:

pentaclemoon.com (in 16 days)
electriclichen.com (in 20 days)
berkeleylug.com (in 26 days)
animelosangeles.com (in 26 days)
chicon.org (in 30 days)
grrattitude.com (in 33 days)
computerhistory.org (in 39 days)
maruch.org (in 43 days)
spinster.org (in 44 days)
lugod.org (in 44 days)
wsfa.org (in 45 days)
badens.org (in 47 days)
linuxdojo.net (in 60 days)
chair-in-the-sky.com (in 65 days)
cain.org (in 65 days)
svlug.net (in 71 days)
nblug.org (in 72 days)
landley.net (in 77 days)
zwilnik.net (in 82 days)
nesfa.org (in 83 days)
mib.org (in 86 days)
whensday.info (in 88 days)
likkitownsend.com (in 90 days)
desamojones.com (in 90 days)

---<end>---


That mail was generated by my local /etc/cron.weekly/domain-check
cron job, which is as follows:


---<begin>---

#! /bin/sh

# domain-check Cron script to check domain expirations.
#
# This is a pitifully primitive cron script to invoke domain-check
# by Ben Okopnik ( ***@linuxgazette.net ) against lists
# of domains in /usr/local/share. A better replacement
# would notify a list of appropriate persons for each
# domain, rather than just Rick Moen.
#
# Written by Rick Moen (***@linuxmafia.com)
# $Id: cron.weekly,v 1.01 2007/07/02 21:03:05 rick

set -o errexit #aka "set -e": exit if any line returns non-true value
set -o nounset #aka "set -u": exit upon finding an uninitialised variable

test -e /usr/local/share/domains || exit 0
test -x /usr/local/bin/domain-check || exit 0


/usr/local/bin/domain-check -w -e=***@linuxmafia.com -x=90 -F=/usr/local/share/domains

---<end>---



My /usr/local/share/domains file is simply an ASCII list of domains
I wish to be periodically checked, listed one per line.

[Anthony via luv-main]

Post by Rick Moen via luv-main

To this day, every Sunday I get e-mail via a cron job that runs
domain-check against a set of about three dozen domains (mine,
friends', and those of institutions I care about) to tell me which of
them are within 90 days of expiration (and if any are past
expiration).

FYI, here's an example report sent using said cron job, that leverages
---<begin>---
Date: Sun, 24 Dec 2017 07:12:02 -0800
Subject: domain-check: Domain expiration warning (90 day cutoff)

Unfortunately you can't poll whois for a .au domain more than 20 times a
day from the same IP.

Australian domain whois also doesn't show expiry info.

[Rick Moen via luv-main]

Post by Anthony via luv-main
Australian domain whois also doesn't show expiry info.

Quite.

This astonishing-to-me-in-2007 fact is highlighted prominently in my
referenced _Linux Gazette_ article. The domain I tested, as revealed in
the article, was, in fact, luv.asn.au. (That revelation means that all
three implementations of the checking script are useless for .au
domains, sadly. Fortunately, even for hosts in Oz, .au is not the only
possible TLD. For hosts where that DNS constraint applies, true, other
solutions would be required.)

Post by Anthony via luv-main
Unfortunately you can't poll whois for a .au domain more than 20 times a
day from the same IP.

FWIW, Ben Okopnik's (and, IIRC, Jesse Monroy's) Perl code includes
rate-limiting code for some _other_ TLDs that are punitive of frequent
queries, albeit not quite that punitive.

[Anthony via luv-main]

The Aus approach was indeed taken due to spam considerations, trying to
limit data mining of whois records (the daily rate limiting), and renewal
scams based upon listed expiry dates (I remember reading through auDA doco
as it came into being after Melbourne IT lost the exclusive gig). I
definitely get more crap from my .com regos, even those with anonymised
WHOIS entries, than I do the .au's I manage (at least those that flog
specifically to the business around the domains). Not to say I agree with
auDA on everything - the upcoming opening of the .au 2LD to willy-nilly
registrations feels like a poor decision to me... just inventing more
"land" for which folks will have to compete... but I guess that's the
nature of a digital economy, and I'm beginning to digress....

Back on track... I think we're seeing the eventual death of WHOIS, due to
GDPR. A double edged sword - I mean, on one hand, it's waaaaay too easy to
scrape and then have third party companies take copies, charging a
subscription to suppress the information (has a feel of extortion). On the
other hand, when helping folks sort out their issues, sometimes they don't
even know who their registrar is, let alone who's the authorised contact
and where their correspondence is being sent..

Hopefully there'll at least be a system that provides base info:

- The registration status of the domain (available, registered, expired,
locked)
- The registrar
- A proxied email address through which to contact the registrant

I figure that shouldn't fall foul of GDPR, let legitimate folks know who
they have to contact to get their domains updated, and let people contact a
domain's registrant if they need to.

[Rick Moen via luv-main]

Post by Anthony via luv-main
The Aus approach was indeed taken due to spam considerations, trying to
limit data mining of whois records (the daily rate limiting), and renewal
scams based upon listed expiry dates (I remember reading through auDA doco
as it came into being after Melbourne IT lost the exclusive gig).

Yes, after initially being astonished at the withholding of expiry dates
in .au domain WHOIS, I read about the rationale, and one must of course
acknowledge that it makes sense.

FWIW, I offered Ben's and Jesse's domain-check scripts as candidate
solutions for Russell's problem because he said merely that he was
seeking a tool to monitor expiration status for _domains_. The
stated context wasn't specifically _.au_ ones -- but, note, I also made
sure to highlight the _Linux Gazette_ article to highlight the .au
roadblock so Russell wouldn't be surprised.

All GTLDs (I think) and _almost_ all country-code TLDs (ccTLD) domains'
data parse fine. (I think.) ICANN keeps creating weird and obscure
GTLDs, though, which is one reason why any tool like Ben's and Jesse's
needs occasional maintenance. And the _other_ reason is that even
long-established TLDs sometimes change their WHOIS date reporting in
ways that break parsing, for no good reason.


To craft a monitoring tool for .au domains, I believe one would need to
write code to login to registrar records as the owner, and parse the
expiry data there. Which _could_ work. Or:
https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454

;->

Post by Anthony via luv-main
Back on track... I think we're seeing the eventual death of WHOIS, due to
GDPR.

Interesting point. WHOIS service, and most particularly classic 43/tcp
WHOIS service, has been the red-headed stepchild for decades for other
reasons, too. For one thing, the current breed of desktop users almost
never even think to use it. MS-Windows doesn't come with a client, and
MacOS X has only a Unix-standard console client, so Macheads typically
never notice it. And, as with the main reason why Gopher was supplanted
by the Web, port-43 WHOIS service is text-bound and non-advertising-friendly.

Quite a few ccTLDs offer WHOIS only via Web front-ends, partly in
consequence.

And now, as you say, argubly there's Yet Another GDPR Objection to deal
with. I fear you're right.
One can conceive of a standard authenticated-owner interface to permit
domain principals to look up such data, sidestepping EU privacy
objections. Maybe. But of course, public ability to check _other_
people's domain details, relied on by Ben and Jesse's tools and frankly
by many people all the time, suffers. E.g., I can't tell you how many
times I've tried to help an acquaintance with, say, his/her domain about
to expire, and the e-mail addresses on record were utterly useless but the
names and telephone numbers of the Registrant, Administrative Contact,
and Technical Contact were crucial.

The 'e-mail addresses prove useless for an unexpectedly expiring domain'
syndrome is predictable, if you think about it: If the listed contact
e-mails had been an effective means of reaching the key people, they
wouldn't have ignored about five or six consecutive renewal notices.

[Bradley D. Thornton via luv-main]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Rick Moen via luv-main
Yes, after initially being astonished at the withholding of expiry
dates in .au domain WHOIS, I read about the rationale, and one must
of course acknowledge that it makes sense.

As an admin I can't say that I concur in the least - especially when
there is the choice of proxies in the form of privacy bureaus.

- --
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: [phone]
-----BEGIN PGP SIGNATURE-----
Comment: Find this cert at hkps://hkps.pool.sks-keyservers.net
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEzBAEBCAAdFiEENWT7St9Eg6sLyiLAuIw5wQytyEkFAlswcR8ACgkQuIw5wQyt
yEn2sgf/ZBmyvLv8SVz/6A3QlPMMZ7EL4oPFbeJZRB28tSlnPYOYfA7Wv7NG8z56
oNUis7ZM8kg6jTHYjd/p14UkkRXS/LsTCpdl6yzYUXjtlmN2XpqocLlZ6U5OI9mI
NSh3+RoLLHwj7WlEaM4Rj4f40etiJAcAeyntwFFRxF1NzL+yS3Q6I4c8SoYRNJwj
sMNSPs1gnEeYKONe+97Q4GRxpVpmnPWUGb3U6Vetvwn/74QH43Hz6N1MESElzYa6
cB5ojIOocmnOTKDTKqdv/9LdP+cimkQsNi3pGZTd1GHUwO9lGT9ZnvfxhtVOWz1b
Q6Lhbl6ZwR9OGnChvKJICMlstLaGkw==
=U2h4
-----END PGP SIGNATURE-----

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Rick Moen via luv-main]

Post by Bradley D. Thornton via luv-main
As an admin I can't say that I concur in the least - especially when
there is the choice of proxies in the form of privacy bureaus.

You'll note I didn't say I agreed with the policy, just that the
rationale made sense. (I expect my overall view ought to be clear given
that I've been trying for over a decade to promote and maintain software
tools that rely on public WHOIS data.)

[Bradley D. Thornton via luv-main]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

1) Their social media chat was a bot 2) They can't run any sort of
web services 3) They keep you on hold for 15 minutes and then the
call drops (automated?) 4) They tell you that they can't do
anything then after 7 calls the same coal face employee can achieve
a task.

Rick offered some valuable tools for you, installing from that github
repo might be a good idea for you.

As far as registrars themselves, I would personally seek out and
transfer away from the current registrar as soon as possible -
following a renewal you may have to wait a bit.

The registration service provider I would recommend would be ALMOST
ANY OpenSRS reseller. It's about as straight forward as you can get,
DNS is free is you like (if your provider offer's the Tucows DNS), etc.

If something happens to your registration services provider you can
merely go directly through Tucows OpenSRS interface too.

The reason I recommend this solution is because there's absolutely no
shennanigans, no inherent upselling (Like GoDaddy or CrazyDomains,
etc.), and you can pick a provider local to you that has chosen to
support the TLDs that you need.

Tucows even offers direct phone support as well, without the
offshore-ish nightmares you experienced. You're local provider may
offer phone support as well.

I've been an OpenSRS provider from the very very beginning, worked on
the documentation, early code and the OpenSRX stuff as well as
OpenSRS. It's rock solid, and a company I used to work for,
MediaTemple, used to use them as well before being acquired by GoDaddy
and moving (reluctantly and much to their chagrin) to WildWest
Domains, which is itself GoDaddy.

I've never had a problem in these decades w/OpenSRS that I couldn't
solve for one of my customers in 20 minutes, which saved a lot of
grief stricken folks and provided much relief to both them as a
customer, and me as their trusted provider.

NO, this is not a shameless plug. Find an OpenSRS provider in your own
local timezone and you *should* receive the same stellar performance
and support from them that I'm able to offer my customers.... without
worrying if that provider is stealing your business brand - like some
horror stories I've seen about some of the other most recognizable
brands in the domain registration arena (not mentioning any names,
like, y'know, register.com or any other provider owned by those SPAMmers
).

Good luck and I am glad to know you regained control over your domain...

Oh, one more thing: I personally have it set up that my customer begin
receiving renewal emails 90 days before expiry. And because my
customers receive so many notifications prior to the expiration of
their domains I do charge an arm and a leg for recovery and
redemption. No one should receive 5 notifications of domain expiry
beginning 90 days prior to such an event, do nothing, let it expire,
and then expect not to be charged for such neglect IMO, as I have to
receive these notifications too and watch it happen.

Kindest regards,

- --
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: [phone]
-----BEGIN PGP SIGNATURE-----
Comment: Find this cert at hkps://hkps.pool.sks-keyservers.net
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEzBAEBCAAdFiEENWT7St9Eg6sLyiLAuIw5wQytyEkFAlswcEcACgkQuIw5wQyt
yEk5igf9F3g9n6aXf5fXY6u7EhO11UJHvWoZBWEL1eHJdXCHchJ04kumAxrF99Kh
d6qt84JiquC3/CFBKvtLZWiWyZhnzMg/BZyw+rVXA6vMO8b0MFupt3qWDccNfGNf
8HPX8d3otDXi5xTl46Y2ikGG9gonVMevCIaC6TGBrz0TLNMmbkIJHSUqzWtLf5YZ
xefiAM3MM8AQwBeCtRGU7N/XkCwKoEASoQfZgv4cDD+wXb2+ZWRFxYY7eDUsLPgT
kgG9QpRmPDysuvRVJQVOwxyYeFQC7bcGm/QZV0v1QTysZXV5i7oCw0w2ZheJ7bGy
69fVHlNDmQq4m0mHvYAg0lk/5eZoEA==
=JQfx
-----END PGP SIGNATURE-----

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus