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

Beeson, Ayden ABeeson at csu.edu.au
Wed Sep 3 11:15:55 EST 2014


My view would be delegation time + standard TTL (86400) + fudge factor (a few hours extra) = time to remove.

If they have a system that currently removes them, it wouldn’t be too hard to simply have that system use a time based calculation like this before it actually does the work.

Imagine if the second you had a port request for a phone number, the losing carrier just started rejecting all calls to that number until the port was complete and it wasn’t their number any more.

That is in essence what they are doing with your DNS zone, though obviously simplified….

Thanks,
Ayden Beeson

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<mailto: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<mailto:joe at apcs.com.au>>
To: ausnog at lists.ausnog.net<mailto: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<mailto:jthorpe at Conexim.com.au>]
>> Sent: Wednesday, 3 September 2014 9:43 AM
>> To: Alex Samad - Yieldbroker; ausnog at lists.ausnog.net<mailto: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<http://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<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<mailto: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<mailto:AusNOG at lists.ausnog.net>
>> http://lists.ausnog.net/mailman/listinfo/ausnog


> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
> http://lists.ausnog.net/mailman/listinfo/ausnog

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog


[cid:csu-logo5f49.bmp]<http://www.csu.edu.au/>

|   ALBURY-WODONGA   |   BATHURST   |   CANBERRA   |   DUBBO   |   GOULBURN   |   MELBOURNE   |   ONTARIO   |   ORANGE   |   PORT MACQUARIE   |   SYDNEY   |   WAGGA WAGGA   |

________________________________
LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia<http://www.csu.edu.au> The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA Provider Number: PV12018
Charles Sturt University in Ontario<http://www.charlessturt.ca/> 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca<http://www.peqab.ca>

[cid:anniversayddc.bmp]

Consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140903/8d496f80/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: csu-logo5f49.bmp
Type: image/bmp
Size: 37976 bytes
Desc: csu-logo5f49.bmp
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140903/8d496f80/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: anniversayddc.bmp
Type: image/bmp
Size: 53864 bytes
Desc: anniversayddc.bmp
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140903/8d496f80/attachment-0003.bin>


More information about the AusNOG mailing list