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

[Mark Andrews]

Firstly please fix you MUA EOL is not encoded as "=0A" in printed-quotable.

This really isn't readable which is the whole point of printed-quotable.

> So let me play devils advocate here, what would you like them to do ?=0A=0A=
> The way I see it they (Melb IT) have two options:=0A=0A1. You delegate the =
> hosting to other NS, they drop the zone from their NS (which is what has be=
> en said below, how it happens NOW)=0A2. 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=0A=0AI think we'd all agree t=
> hat it's pointless (and bad form) to have zones kicking around on your NS t=



In message <1409706114.80607.YahooMailNeo at web122103.mail.ne1.yahoo.com>, Tony writes:
>
> 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

3. They set a 1 week timer and remove the zones after 1 week after
the NS records have been changed. 

This isn't rocket science.  It is not hard to put a timer into a
process.  With DNSSEC it becomes even more important that transfers
be handled properly.

> 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.

The delegation has not gone until the cached record have expired.

> 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 !)

Which is why scripts like this start timers.  Computers are good at
queuing thing up to happen later.

	"at now + 7d remove $zone"

> 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.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org