Authoritative Server - Referrals to root

[Joe Greco]

> 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.
>
> So, in the OP's situation, they're removing a zone because the customer 
> hasn't paid.

That's an interesting scenario.  I find myself wondering if that's a design
flaw or merely a good reason to keep paid up on your bills.

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

While that's a reasonable workaround, I think it also answers what I was
wondering above:  it's a design flaw (somewhere).

The reality of the Internet is that you cannot and should not expect any
remote host to go doing you any favors, and in fact, there is no reason 
to expect that such hosts would not return an answer that was as
unfavorable to you as possible.

That implies that for any given recurser, cached records which are
dependent upon information located via glue records which would have 
expired at the time a new request is being processed ought to be subject 
to some additional consideration.  Perhaps re-verification of glue
records, followed by an elimination of all dependent data in the event
that the glue has changed.

I can see that as being fun to compute (not), but without steps like that,
it seems the door would be open to a variety of abuses.

In the ideal world, I guess it would simply be nice if providers were
willing and able to coordinate zone transfers a little better.  Most of
them seem to freak at basic things like lowering the TTL...  good luck
trying to actually get a zone transfer of the current data.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.