Authoritative Server - Referrals to root

[Mark Andrews]

> In article <d34c5l$r6r$1 at sf1.isc.org>, Joe Greco <jgreco at ns.sol.net> 
> wrote:
> 
> > There is no operational reason that our authoritative nameservers here 
> > cannot think that they're authoritative for, let's say, isc.org.  It has 
> > no operational impact on anybody even if we did, because nothing would
> > ever cause queries for isc.org to be routed to our authoritative
> > nameservers.  That's the difference between a closed-for-abuse customer
> > and the situation you're painting it as.
> 
> There can often be problems during transitions, though.  If a zone used 
> to be delegated to you, someone may still have the cached delegation.  
> And if you are also authoritative for the zone, you'll keep updating 
> their NS records every time they query you, so they'll never go back to 
> the TLD server to get the new delegation.  We had a thread a few weeks 
> ago about this type of problem.

	A low TTL on the NS RRset will prevent / reduce the probability
	of cache being locked in especially if you make the negative
	response have a longer TTL than the NS RRset.
 
> So, in the OP's situation, they're removing a zone because the customer 
> hasn't paid.  If the customer switches to a new provider, they'll 
> presumably update the delegations.  But if the OP left the empty zone on 
> his server, some caches may never notice the switch.
> 
> What he *could* do is monitor the delegations for the zones that he's 
> invalidating.  As long as it's delegated to him, he should continue to 
> host the empty zone to avoid the request looping problem that he ran 
> into.  Once the delegation changes, he should remove the zone.

	Agreed.  He should be doing that so he can cleanup.
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org