[AusNOG] Am I being unreasonable.... MelbourneIT

Joshua D'Alton joshua at railgun.com.au
Wed Sep 3 23:40:13 EST 2014


Uh, registrar**, autocorrect sorry!


On Wed, Sep 3, 2014 at 11:37 PM, Wolfgang Nagele (AusRegistry) <
wolfgang.nagele at ausregistry.com.au> wrote:

>  Hi,
>
>  Could you please elaborate what you are referring to with AU registry
> ‘issues’? Happy to discuss off-list if you prefer but we’re taking the
> registry operations very serious and I’d like to know of any issues.
>
>  Normally you won’t interact directly with us anyway as our systems are
> only connected to by registrars. But we’d still like to know if there are
> problems with registrars - at a minimum we might be able to help getting
> the right people involved there to resolve them.
>
>  Thanks,
>
>  --
> Wolfgang Nagele
> IT Manager
> AusRegistry Pty Ltd
> Level 8, 10 Queens Road
> Melbourne, Victoria, Australia, 3004
> Phone +61 3 9866 3710
> Email: wolfgang.nagele at ausregistry.com.au
> Web: www.ausregistry.com.au
>
>  A Bombora Technologies company
>
>
>  The information contained in this communication is intended for the
> named recipients only. It is subject to copyright and may contain legally
> privileged and confidential information and if you are not an intended
> recipient you must not use, copy, distribute or take any action in reliance
> on it. If you have received this communication in error, please delete all
> copies from your system and notify us immediately.
>
>   On 9/3/14, 11:14 PM, "Joshua D'Alton" <joshua at railgun.com.au> wrote:
>
>   Maybe it has been bourne from years of dealing with problems like this
> that long ago I decided I'd never mix registrar and DNS/NS. I had used a
> few different combinations, lately (2-3 years) I've switched to cloudflare
> for DNS. Both for personal and business needs, I haven't come across any
> problems with DNS, and then likewise removing that single point of failure,
> I'd not been bitten by some of the recent AU registry 'issues'.
>
>  I feel a "one does not simply mix DNS with registry" LOTR meme here ;)
>
>  Good luck sorting it all out!
>
>
> On Wed, Sep 3, 2014 at 7:35 PM, Damien Gardner Jnr <rendrag at rendrag.net>
> wrote:
>
>> Well if it was *just* dns, it's not really a huge issue..  I was more
>> thinking where it's a customer's whole hosting, which might be more like
>> 30-40gb of emails, web, database, etc..  That does cost to have sitting
>> there doing nothing.. :)
>>
>>
>> On 3 September 2014 17:57, Chard, Alex (REA-SYD) <
>> Alex.Chard at reed-elsevier.com.au> wrote:
>>
>>>  Yes, I do understand this point.. but for DNS in particular, how much
>>> extra does it cost you to maintain that zone?
>>> I would have thought its cheap enough that you can afford to not
>>> clean-up for say 3 months and not notice (or even be able to quantify) the
>>> impact to your bottom line.
>>>
>>>
>>>
>>> --Alex
>>>
>>>
>>>
>>> *From:* Damien Gardner Jnr [mailto:rendrag at rendrag.net]
>>> *Sent:* Wednesday, 3 September 2014 1:17 PM
>>> *To:* Chard, Alex (REA-SYD)
>>> *Cc:* ausnog at lists.ausnog.net
>>>
>>> *Subject:* Re: [AusNOG] Am I being unreasonable.... MelbourneIT
>>>
>>>
>>>
>>> As much as I disagree with removing a zone as soon as a customer changes
>>> their delegation, I can kinda see where they're coming from.
>>>
>>>
>>>
>>> The amount of times I've had a customer get to 2-3 months past due on an
>>> invoice (Ok, that doesn't happen anymore, I got jack of it, and accounts
>>> get suspended 14 days past due, and accounts terminated and all data
>>> deleted a further 14 days later), and when you finally get onto them to let
>>> them know you're going to debt collection, and they come back with a 'Oh,
>>> but we moved away from you four months ago!  Why would we pay you?' is
>>> really quite disturbing.   Customers just don't understand that if the
>>> general internet sees it as going to another Host, that it's still costing
>>> the old Host money to have sitting there (without starting an argument
>>> about separating authoritative and recursive DNS on the network).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 3 September 2014 13:08, Chard, Alex (REA-SYD) <
>>> Alex.Chard at reed-elsevier.com.au> wrote:
>>>
>>>  Seems to me the correct way to solve this issue would be to charge a
>>> (small) fee for the DNS hosting.
>>>
>>> That way, customers will be aware that they have a DNS zone on your DNS
>>> servers (via their bill), and have some incentive to clean up if they
>>> delegate away.
>>>
>>>
>>>
>>> If you do end up with zones that are not delegated to your DNS servers…
>>> doesn’t matter, you’re being paid to host them.
>>>
>>>
>>>
>>> To the actual issue here… can you tell the DNS host that you wish to use
>>> them as a secondary/tertiary DNS host until your migration is complete?
>>>
>>>
>>>
>>> From what I’ve seen, MelbourneIt have gone downhill over the last few
>>> years. We have almost entirely migrated away from their registrar services
>>> since they sold their corporate arm to CSC because of poor service.
>>>
>>>
>>>
>>> --Alex Chard
>>>
>>>
>>>
>>> *From:* AusNOG [mailto:ausnog-bounces at lists.ausnog.net] *On Behalf Of *
>>> Tony
>>>
>>>
>>> *Sent:* Wednesday, 3 September 2014 11:02 AM
>>> *To:* Joseph Goldman; ausnog at lists.ausnog.net
>>>
>>> *Subject:* Re: [AusNOG] Am I being unreasonable.... MelbourneIT
>>>
>>>
>>>
>>> So let me play devils advocate here, what would you like them to do ?
>>>
>>>
>>>
>>> The way I see it they (Melb IT) have two options:
>>>
>>>
>>>
>>> 1. You delegate the hosting to other NS, they drop the zone from their
>>> NS (which is what has been said below, how it happens NOW)
>>>
>>> 2. They keep the zone active on their NS while you set it up at another
>>> provider and then at some later point in time you/they have to remove it
>>> from their NS
>>>
>>>
>>>
>>> I think we'd all agree that it's pointless (and bad form) to have zones
>>> kicking around on your NS that are not delegated to that NS. It's untidy
>>> and worse case is it will produce false replies for anyone that happens to
>>> try and lookup something from that zone from the 'old' NS.
>>>
>>>
>>>
>>> So if they were to go with the 2nd option they run the risk that this
>>> will happen, old/stale zones that are no longer delegated to Melb IT NS,
>>> but still exist on them. The only way to avoid these stale zones would be
>>> to either:
>>>
>>>
>>>
>>> i). Rely on customer to delete them (or create a ticket to say migration
>>> was complete and they can now be deleted).
>>>
>>> ii). Have some sort of script that runs on a daily/weekly basis and
>>> compares zones delegated to zones that exist on NS and delete any zones
>>> that are no longer delegated to Melb IT NS.
>>>
>>>
>>>
>>> We all know that relying on customers to do anything is fraught with
>>> problems. If you want it done, you need to do it yourself. Also remember
>>> that a good proportion of Melb IT customers may not be so DNS literate.
>>>
>>>
>>>
>>> If they scripted it, you just increase your work load, have potential
>>> for problem and still potentially have people who would complain because
>>> the script ran at 2300 Friday and they had started the redelegation process
>>> at 2200 Friday (ie. 1 hour before script start) and so they still wanted
>>> the domain to stay on the old NS for another few days (of course you could
>>> mitigate against this by checking each day and flagging stuff as "to be
>>> deleted" then leaving it for a few more days before it actually gets
>>> deleted, but really how far do you take this !)
>>>
>>>
>>>
>>>
>>>
>>> It's a bit of a hard line, but I can see where they are coming from. It
>>> hopefully produces the most consistent result for all at the end of the day
>>> and saves them wasting resources. You're no longer wishing to use their NS,
>>> why should the zone continue to exist on their NS ?
>>>
>>>
>>>
>>>
>>>
>>> At least now that you know about it, you can factor it into your
>>> migration process.
>>>
>>>
>>>
>>>
>>>
>>> regards,
>>>
>>> Tony.
>>>
>>>
>>>
>>>
>>>
>>>
>>>    ------------------------------
>>>
>>> *From:* Joseph Goldman <joe at apcs.com.au>
>>> *To:* ausnog at lists.ausnog.net
>>> *Sent:* Wednesday, 3 September 2014 9:54 AM
>>> *Subject:* Re: [AusNOG] Am I being unreasonable.... MelbourneIT
>>>
>>>
>>> Yikes thats harsh.
>>>
>>> See if you can set your TTL's down real low for the important records
>>> (A, MX etc) wait a day or 2 then do it - at least hopefully then the
>>> world is aware of low TTL and the time from them removing from their
>>> NS's to servers checking your new ones should be quick.
>>>
>>> On 03/09/14 09:50, Alex Samad - Yieldbroker wrote:
>>> > Yep that was my thought.
>>> >
>>> > So I have setup my master DNS, setup my secondary, tested against
>>> their NS.
>>> >
>>> > Went to the Melbourne IT site.
>>> > Went to re delegate... then it says you can't, you have to un manage
>>> it from MelbourneIT and it has to be done first.
>>> >
>>> > Basically it deletes it from their NS servers, happens almost
>>> immediately, I checked against their NS servers.
>>> >
>>> > I have a few domains that I am looking at moving over... So this is
>>> going to be a painful task.
>>> >
>>> > Alex
>>> >
>>> >> -----Original Message-----
>>> >> From: Jonathan Thorpe [mailto:jthorpe at Conexim.com.au]
>>> >> Sent: Wednesday, 3 September 2014 9:43 AM
>>> >> To: Alex Samad - Yieldbroker; ausnog at lists.ausnog.net
>>> >> Subject: RE: Am I being unreasonable.... MelbourneIT
>>> >>
>>> >> Hi Alex,
>>> >>
>>> >> That doesn't sound right to me.
>>> >>
>>> >> The domain delegation and authoritative DNS are usually handled
>>> >> independently.
>>> >>
>>> >> It should be a matter of:
>>> >> 1. Set up the DNS records on the new service.
>>> >> 2. Re-delegate the domain to the new nameservers.
>>> >>
>>> >> If you've set up new nameservers with new records already, then you
>>> should
>>> >> be able to login to the Melbourne IT management console and perform
>>> the
>>> >> re-delegation yourself.
>>> >>
>>> >> Once this is done, allow 24-48 hours for the change to propagate
>>> (this will
>>> >> depend on the TTLs), then cancel the DNS service.
>>> >>
>>> >> Kind Regards,
>>> >> Jonathan Thorpe
>>> >>
>>> >> --
>>> >> Conexim Australia Pty. Limited | www.conexim.com.au
>>> >> Phone: 1300 133 900 | Fax: 1300 851 747 | Direct: 02 8214 5804 Managed
>>> >> Hosting Excellence | Australian Government Endorsed Supplier
>>> >>
>>> >> Please consider the environment before printing this e-mail
>>> >>
>>> >> PRIVATE & CONFIDENTIAL
>>> >> This email message and attachments contain information that is
>>> confidential
>>> >> to Conexim Australia Pty Limited. If you are not the intended
>>> recipient you
>>> >> are not permitted to use, copy or distribute the message and or
>>> attachments
>>> >> in any manner. If you have received this email in error, please
>>> inform the
>>> >> sender by return email immediately and delete all copies of the
>>> message and
>>> >> any attachments. Conexim Australia Pty Limited is not responsible for
>>> any
>>> >> unauthorised changes made to this email or its attachments. This
>>> notice
>>> >> should not be removed.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> -----Original Message-----
>>> >> From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of
>>> Alex
>>> >> Samad - Yieldbroker
>>> >> Sent: Wednesday, 3 September 2014 9:34 AM
>>> >> To: ausnog at lists.ausnog.net
>>> >> Subject: [AusNOG] Am I being unreasonable.... MelbourneIT
>>> >>
>>> >> Hi
>>> >>
>>> >> So I have decided to move my zone from Melbourne IT.
>>> >>
>>> >> But there is a hitch, seems like Melbourne IT will delete my zone off
>>> their NS
>>> >> before they start the root re delegation.
>>> >>
>>> >> Just spent a 10-15 min talking to their support (24x7), which is
>>> really only 10-5.
>>> >>
>>> >> I remember before, you just went to a web site with your zone key made
>>> >> the NS changes and off you go. Takes 24-48 hours for it to propagate
>>> >> depending on TTL's.  Now that function seems to be with the
>>> registrars and
>>> >> Melbourne IT don't want to play nice.
>>> >>
>>> >> Seems to be like they are just making it hard to move off melbIT...
>>> >>
>>> >> A
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> AusNOG mailing list
>>> >> AusNOG at lists.ausnog.net
>>> >> http://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>>
>>>
>>>
>>> > _______________________________________________
>>> > AusNOG mailing list
>>> > AusNOG at lists.ausnog.net
>>> > http://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>>
>>>
>>> This e-mail is for the use of the intended recipient(s) only. If you
>>> have received this e-mail in error, please notify the sender immediately
>>> and then delete it. If you are not the intended recipient, you must not
>>> use, disclose or distribute this e-mail without the author's permission. We
>>> have taken precautions to minimise the risk of transmitting software
>>> viruses, but we advise you to carry out your own virus checks on any
>>> attachment to this e-mail. We cannot accept liability for any loss or
>>> damage caused by software viruses.
>>>
>>>
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Damien Gardner Jnr
>>> VK2TDG. Dip EE. GradIEAust
>>> rendrag at rendrag.net -  http://www.rendrag.net/
>>> --
>>> We rode on the winds of the rising storm,
>>>  We ran to the sounds of thunder.
>>> We danced among the lightning bolts,
>>>  and tore the world asunder
>>>    This e-mail is for the use of the intended recipient(s) only. If you
>>> have received this e-mail in error, please notify the sender immediately
>>> and then delete it. If you are not the intended recipient, you must not
>>> use, disclose or distribute this e-mail without the author's permission. We
>>> have taken precautions to minimise the risk of transmitting software
>>> viruses, but we advise you to carry out your own virus checks on any
>>> attachment to this e-mail. We cannot accept liability for any loss or
>>> damage caused by software viruses.
>>>
>>
>>
>>
>>  --
>>
>> Damien Gardner Jnr
>> VK2TDG. Dip EE. GradIEAust
>> rendrag at rendrag.net -  http://www.rendrag.net/
>> --
>> We rode on the winds of the rising storm,
>>  We ran to the sounds of thunder.
>> We danced among the lightning bolts,
>>  and tore the world asunder
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140903/d1dd27f9/attachment.html>


More information about the AusNOG mailing list