Subject: Re: [dnsext] Clarification on RFC 2181

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Jul 2009 12:20:09 -0400

At 16:49 +0100 7/2/09, George Barwood wrote:

>and updates the parent and child zone files.

You are confusing authoritative zones and the cache.

In RFC 1034, 4.3.2, take a note of step 2:

    2. Search the available zones for the zone which is the nearest
       ancestor to QNAME.  If such a zone is found, go to step 3,
       otherwise step 4.

And step 4:

    4. Start matching down in the cache.  If QNAME is found in the
       cache, copy all RRs attached to it that match QTYPE into the
       answer section.  If there was no delegation from
       authoritative data, look for the best one from the cache, and
       put it in the authority section.  Go to step 6.

The cache is not divided into zones, like the 
authoritative data is.  The significance is that 
the authoritative data is first divided by zone, 
then by "location" in the zone.  The cache is 
just a tree representing all else it has.  (The 
name with the NS set is not linked to the name in 
the NS set, owning the A record.)  And then 
there's the negative cache.  (This is why cache 
servers can't act like authorities.)

>When the original A record expires from the resolver cache, the original NS
>record will remain for some time, but there is no hope of resolving it.

There is hope.  There is always hope.  The server 
in question simply asks for the needed A 
(/address) record.

>The resolver will go to the parent, and receive the new NS and A record,
>but since the child NS has priority by RFC 2181, the NS will not be replaced,
>and there will be a blackout until the original NS record expires.

The NS is not replaced because you aren't asking 
for that.  You do use the A record to ask the 
query again.

>Section 5.4 does state
>"The challenge for the server is to determine which of the data sets is
>  correct, if one is, and retain that, while ignoring the other."
>
>It seems to me that to avoid problems newly fetched data from the Parent
>should replace old child data, but this seems contrary to 5.4.1.
>
>So I'm feeling somewhat conflicted/confused - help!
>¶-§"æìr¸›zÇ§u©ž"Æ zÚ'jg®Šiz»+z«ž"Ú)"'-~ŠàÂ+a¶°¢·nžË›±Êâmè§jÈ§‚W¥Šwš"Ø^™ë,j-{[¡Üš-Èb½èm¶Ÿÿ¢›"z×è®åŠËlþv¦yÚè¦—«"

For some reason, most of the mail I see sent by 
you (George) has a garbled ending.  Just FYI.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 02 Jul 2009 16:18:17 +0000

> From: "George Barwood" <[email-masked]>
> Date: Thu, 2 Jul 2009 16:49:03 +0100

> ..., it seems that problems can arise if glue A records expire before NS
> records.
> 
> Example:
> 
> example.com 432000 NS ns.example.com
> ns.example.com 1000 A 1.2.3.4
> 
> Suppose a resolver has fetched these records from the child zone.
> Now suppose that administrator changes the zone to
> 
> example.com 432000 NS ns1.example.com
> ns1.example.com 1000 A 1.2.3.4
> 
> When the original A record expires from the resolver cache, the original
> NS record will remain for some time, but there is no hope of resolving
> it.  The resolver will go to the parent,

why?  the resolver already has a zone cut, it has no reason to iterate
through the parent until the zone cut (NS+A) in its cache expires.

>                                           and receive the new NS and A
> record, 

as above, it won't be receiving any such new NS+A until it has a reason
to iterate through the parent again, which means, until after the current
in-cache NS+A expires.

> but since the child NS has priority by RFC 2181, the NS will not
> be replaced, and there will be a blackout until the original NS record
> expires.
> 
> Section 5.4 does state 

for this question to be sequitur, you'd have to assume that the recursive
server was going to periodically revalidate its cached delegation points.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Jul 2009 13:00:06 -0400

At 17:41 +0100 7/2/09, George Barwood wrote:

So asking for the old record will never succeed.
The old NS RRset is useless, no good, unstuck, hopeless, dead and buried.

The failure there is in the operations, not the protocol, for 
removing the old A record before caches have time to learn a new (NS) 
set.

Kind of like "Your car will allow you to steer into that tree.  Just 
don't do it."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 2 Jul 2009 14:08:17 -0400 (EDT)

On Thu, 2 Jul 2009, George Barwood wrote:

> RFC 2181, section 5.4.1 makes it clear that the NS from a child is
> "more trustworthy" than a NS from the parent. I have some issues with this
> notion of "trust", since both parent and child must be trusted regardless.
> But leaving that aside, it seems that problems can arise if glue A records
> expire before NS records.
>
> Example:
>

Operator error, there is nothing that the protocol can do to prevent
mistakes like this cause problems.

DNS has number of timing windows that have to be respected or
things cani/will go wrong, in this case:
ns.example.com should not have been removed until after all instances
of the prior NS set had expired from caches.

 	Olafur

---

From: bert hubert <[email-masked]>
Date: Thu, 2 Jul 2009 20:34:29 +0200

> The old NS RRset is useless, no good, unstuck, hopeless, dead and buried.

You'll find that all 'heavy duty' resolvers have code to deal with
'useless rrsets' to make sure parents are (re-)consulted, but not too
often.

    Bert

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 2 Jul 2009 23:32:14 +0300

> 'useless rrsets' to make sure parents are (re-)consulted, but not too

It's clear from RFC1035 that you sometimes have to re-consult the parent:

     The resolver may encounter a situation where no addresses are
     available for any of the name servers named in SLIST, and
     where the servers in the list are precisely those which would
     normally be used to look up their own addresses.  This
     situation typically occurs when the glue address RRs have a
     smaller TTL than the NS RRs marking delegation, or when the
     resolver caches the result of a NS search.  The resolver
     should detect this condition and restart the search at the
     next ancestor zone, or alternatively at the root.

The question is, when you do have to re-consult the parent (or
"restart the search" as RFC1035 puts it), do you override the NS RRset
you already have (but for which you have no addresses) with the new
one you get from the parent, even if the one you have was obtained
from an "authoritative" source and the new one was not?

My take is that you do override it, RFC2181 be damned.  Preferring
authoritative data over non-authoritative is fine for the purpose of
constructing responses to clients, but it's a bad idea for the purpose
of determining which servers to query.

People tend get hung up on the term "authoritative".  The way it's
defined, the NS records on the child side are "authoritative" and the
ones on the parent side are not.  But the authority of the child stems
from a delegation, and that delegation is granted by the parent, not
just asserted by the child.  If it weren't for the non-authoritative NS
records in the parent, the child wouldn't be authoritative for its NS
records in the first place.

A resolver must respect the parent's prerogative to delegate,
redelegate, and withdraw delegation from its children, which is more
fundamental than the child's right to be considered "authoritative".
If a resolver prefers the child's authoritative NS records over the
parent's delegating NS records for the purpose of determining who is
the correct delegee, it will not only be subject to the problem George
described (which I'm sure can be worked around in other ways), but
will also be vulnerable to other issues, such as former domain owners
hanging on to domains they no longer own by continuing to publish
their old "authoritative" NS records, perhaps with huge TTLs.
-- 
Andreas Gustafsson, [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 02 Jul 2009 23:01:04 +0000

> Date: Thu, 2 Jul 2009 23:32:14 +0300
> From: [email-masked] (Andreas Gustafsson)
> 
> bert hubert wrote:
> ...
> constructing responses to clients, but it's a bad idea for the purpose of
> determining which servers to query.
> 
> ...

so a reasonable policy might be that if all nameserver names are unreachable
then put the delegation in a hold-down state for 180+random(90) seconds during
which you servfail all queries requiring that delegation be followed, and then
discard the NS RRset, so that subsequent queries will cause re-iteration via
the parent, hopefully to get reachable nameservers next time?

this fits with RFC 2181 since by the time new delegation responses come from
the parent, the previously-cached child apex NS RRset will be gone.  it also
leaves it up to the zone's editor/operator to complete screw himself/herself
if the parent's delegation results in reachability whereas the child apex NS
RRset results in unreachability.  that problem should remain out of scope!

---

From: Mark Andrews <[email-masked]>
Date: Fri, 03 Jul 2009 11:43:42 +1000

> you (George) has a garbled ending.  Just FYI.

This is the mailing list software adding this to the end of a base64 encoded
body without adding a new mime section.  I've complained about this already
but no-one seems to want to fix / upgrade the mailing list software.

Adding it either makes the messages completely unreadable or adds "garbage"
to the end.  In neither case does the information make it through.

Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 3 Jul 2009 12:10:50 +0300

> the parent, hopefully to get reachable nameservers next time?

When you say "nameserver names are unreachable", do you mean we lack
addresses for them or that we have addresses but fail to get a
response when querying them?  To be clear, I'm talking about the
former case.

Discarding the cached NS RRset is a resonable way to force the
resolution process to restart at the parent, but I don't see a need
to force SERVFAILs or to wait for a hold-down period.  You can
immediately restart the current resolution using the pruned cache,
taking care to avoid infinite loops as always.
-- 
Andreas Gustafsson, [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Fri, 03 Jul 2009 09:24:42 +0000

> the parent, hopefully to get reachable nameservers next time?

Sure, seems to make sense, and it's claimed regularly that this such a
common practice (with too agressive probing) that large zone operators
have a vested interest in delegations working almost all the time.

If resolver implementors actually implemented this---and something
very similar for a certain range of validation failures, we wouldn't
have to talk about how to properly handle NS/DS migrations.  But I
believe this merely a quality-of-implementation issue for resolvers.
It's not something the protocol specs should be concerned with.  A
"how to be a good citizen's resolver' document would probably cover
it, but the protocol specs always allow to discard cache contents for
protocol-external reasons (all cache management is just that).

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Florian Weimer <[email-masked]>
Date: Fri, 03 Jul 2009 09:54:20 +0000

> taking care to avoid infinite loops as always.

This will essentiall turn off caching of delegations where the child
zone is misconfigured in a particular way.  This may not be a good
idea.  I think you should back off instead, not flooding the parent
zone with queries.

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 3 Jul 2009 14:32:46 +0300

Florian Weimer wrote:
> zone is misconfigured in a particular way.

Which particular way would that be?  I can imagine something like this
happening in a resolver that prefers child data over parent data for
purposes of locating the child servers, but the point I'm trying to
make is that resolvers shouldn't do that.
-- 
Andreas Gustafsson, [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Fri, 03 Jul 2009 12:01:16 +0000

* Andreas Gustafsson:

> Which particular way would that be?

A child zone which looks like this:

@ IN SOA ...
@ IN A 192.0.2.1
@ IN NS ns

That is, record for "ns".  The delegation uses something else not
involving "ns".

> I can imagine something like this happening in a resolver that
> prefers child data over parent data for purposes of locating the
> child servers, but the point I'm trying to make is that resolvers
> shouldn't do that.

I'm generally sympathetic to that.  But this will make it more
difficult to pull DNS traffic over to IPv6.  (I guess the primary
application of deliberate glue mismatch is to introduce AAAA records.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 3 Jul 2009 17:03:11 +0200

On Thu, Jul 02, 2009 at 02:08:17PM -0400,
 Olafur Gudmundsson <[email-masked]> wrote 
 a message of 38 lines which said:

> DNS has number of timing windows that have to be respected or things
> cani/will go wrong, in this case: ns.example.com should not have
> been removed until after all instances of the prior NS set had
> expired from caches.

And, of course, such timing rules will be *much* more important with
DNSSEC, which will soon bring to a name server near you, a lot more
ways to crash your service :-)

---

From: Paul Vixie <[email-masked]>
Date: Fri, 03 Jul 2009 16:50:11 +0000

> Date: Fri, 3 Jul 2009 12:10:50 +0300
> > so a reasonable policy might be that if all nameserver names are
> > unreachable then put the delegation in a hold-down state for
> > 180+random(90) seconds during which you servfail all queries requiring
> > that delegation be followed, and then discard the NS RRset, so that
> > subsequent queries will cause re-iteration via the parent, hopefully to
> > get reachable nameservers next time?
> 
> addresses for them or that we have addresses but fail to get a response
> when querying them?  To be clear, I'm talking about the former case.

i am likewise talking about the former case, although i might expand the
definition of unreachable to include "all addresses are returning servfail
or refused".

> Discarding the cached NS RRset is a resonable way to force the resolution
> process to restart at the parent, but I don't see a need to force
> SERVFAILs or to wait for a hold-down period.  You can immediately restart
> the current resolution using the pruned cache, taking care to avoid
> infinite loops as always.

without the holddown, this approach overwhelms the parent zone's servers.

without the servfail, the question becomes, how to answer the downstream.

---

From: "George Barwood" <[email-masked]>
Date: Fri, 3 Jul 2009 19:57:33 +0100

VGhlcmUgYXJlIGEgbGFyZ2UgbnVtYmVyIG9mIG1pcy1jb25maWd1cmF0aW9ucyB0aGF0IGNhbiBjYXVzZSANCmxvb3BzIHRvIG9jY3VyLCBzbyByZXNvbHZlcnMgbmVlZCBhIGdlbmVyYWwgbWV0aG9kIG9mIGxpbWl0aW5nDQp0aGUgbnVtYmVyIG9mIHF1ZXJpZXMgdGhhdCBjYW4gYmUgZ2VuZXJhdGVkIGluIHJlc3BvbnNlIHRvIGEgDQpxdWVyeS4gVGhpcyBpcyBhZGVxdWF0ZWx5IGNvdmVyZWQgaW4gUkZDIDEwMzUgOg0KDQoiVGhlIGFtb3VudCBvZiB3b3JrIHdoaWNoIGEgcmVzb2x2ZXIgd2lsbCBkbyBpbiByZXNwb25zZSB0byBhDQogY2xpZW50IHJlcXVlc3QgbXVzdCBiZSBsaW1pdGVkIHRvIGd1YXJkIGFnYWluc3QgZXJyb3JzIGluIHRoZSBkYXRhYmFzZS4uLiINCg0KSWYgcmVzb2x2ZXJzIGNhbiBkZXRlY3QgbG9vcGluZyBtaXMtY29uZmlndXJhdGlvbnMgYmVmb3JlIHRoaXMgDQpnZW5lcmFsIHNhZmVndWFyZCBpcyB0cmlnZ2VyZWQsIHRoYXQgaXMgZ29vZCwgYnV0IGl0J3Mgbm90IGVzc2VudGlhbC4NCg0KSSB0aGluayBpdCdzIHJlYXNvbmFibGUgdG8gaWdub3JlIGNoaWxkIE5TIFJSc2V0cyB3aGljaCBoYXZlIG1pc3NpbmcgDQpyZXF1aXJlZCBnbHVlLCBidXQgdGhpcyBpcyByZWFsbHkgYW5vdGhlciB0b3BpYy4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJGbG9yaWFuIFdlaW1lciIgPGZ3ZWltZXJAYmZrLmRlPg0KVG86ICJBbmRyZWFzIEd1c3RhZnNzb24iIDxnc29uQGFyYW5ldXMuZmk+DQpDYzogIlBhdWwgVml4aWUiIDx2aXhpZUBpc2Mub3JnPjsgPG5hbWVkcm9wcGVyc0BvcHMuaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIEp1bHkgMDMsIDIwMDkgMTowMSBQTQ0KU3ViamVjdDogUmU6IFtkbnNleHRdIENsYXJpZmljYXRpb24gb24gUkZDIDIxODENCg0KDQoqIEFuZHJlYXMgR3VzdGFmc3NvbjoNCg0KPiBGbG9yaWFuIFdlaW1lciB3cm90ZToNCj4+ID4gRGlzY2FyZGluZyB0aGUgY2FjaGVkIE5TIFJSc2V0IGlzIGEgcmVzb25hYmxlIHdheSB0byBmb3JjZSB0aGUNCj4+ID4gcmVzb2x1dGlvbiBwcm9jZXNzIHRvIHJlc3RhcnQgYXQgdGhlIHBhcmVudCwgYnV0IEkgZG9uJ3Qgc2VlIGEgbmVlZA0KPj4gPiB0byBmb3JjZSBTRVJWRkFJTHMgb3IgdG8gd2FpdCBmb3IgYSBob2xkLWRvd24gcGVyaW9kLiAgWW91IGNhbg0KPj4gPiBpbW1lZGlhdGVseSByZXN0YXJ0IHRoZSBjdXJyZW50IHJlc29sdXRpb24gdXNpbmcgdGhlIHBydW5lZCBjYWNoZSwNCj4+ID4gdGFraW5nIGNhcmUgdG8gYXZvaWQgaW5maW5pdGUgbG9vcHMgYXMgYWx3YXlzLg0KPj4gDQo+PiBUaGlzIHdpbGwgZXNzZW50aWFsbCB0dXJuIG9mZiBjYWNoaW5nIG9mIGRlbGVnYXRpb25zIHdoZXJlIHRoZSBjaGlsZA0KPj4gem9uZSBpcyBtaXNjb25maWd1cmVkIGluIGEgcGFydGljdWxhciB3YXkuDQo+DQo+IFdoaWNoIHBhcnRpY3VsYXIgd2F5IHdvdWxkIHRoYXQgYmU/DQoNCkEgY2hpbGQgem9uZSB3aGljaCBsb29rcyBsaWtlIHRoaXM6DQoNCkAgSU4gU09BIC4uLg0KQCBJTiBBIDE5Mi4wLjIuMQ0KQCBJTiBOUyBucw0KDQpUaGF0IGlzLCByZWNvcmQgZm9yICJucyIuICBUaGUgZGVsZWdhdGlvbiB1c2VzIHNvbWV0aGluZyBlbHNlIG5vdA0KaW52b2x2aW5nICJucyIuDQoNCj4gSSBjYW4gaW1hZ2luZSBzb21ldGhpbmcgbGlrZSB0aGlzIGhhcHBlbmluZyBpbiBhIHJlc29sdmVyIHRoYXQNCj4gcHJlZmVycyBjaGlsZCBkYXRhIG92ZXIgcGFyZW50IGRhdGEgZm9yIHB1cnBvc2VzIG9mIGxvY2F0aW5nIHRoZQ0KPiBjaGlsZCBzZXJ2ZXJzLCBidXQgdGhlIHBvaW50IEknbSB0cnlpbmcgdG8gbWFrZSBpcyB0aGF0IHJlc29sdmVycw0KPiBzaG91bGRuJ3QgZG8gdGhhdC4NCg0KSSdtIGdlbmVyYWxseSBzeW1wYXRoZXRpYyB0byB0aGF0LiAgQnV0IHRoaXMgd2lsbCBtYWtlIGl0IG1vcmUNCmRpZmZpY3VsdCB0byBwdWxsIEROUyB0cmFmZmljIG92ZXIgdG8gSVB2Ni4gIChJIGd1ZXNzIHRoZSBwcmltYXJ5DQphcHBsaWNhdGlvbiBvZiBkZWxpYmVyYXRlIGdsdWUgbWlzbWF0Y2ggaXMgdG8gaW50cm9kdWNlIEFBQUEgcmVjb3Jkcy4pDQoNCi0tIA0KRmxvcmlhbiBXZWltZXIgICAgICAgICAgICAgICAgPGZ3ZWltZXJAYmZrLmRlPg0KQkZLIGVkdi1jb25zdWx0aW5nIEdtYkggICAgICAgaHR0cDovL3d3dy5iZmsuZGUvDQpLcmllZ3NzdHJh32UgMTAwICAgICAgICAgICAgICB0ZWw6ICs0OS03MjEtOTYyMDEtMQ0KRC03NjEzMyBLYXJsc3J1aGUgICAgICAgICAgICAgZmF4OiArNDktNzIxLTk2MjAxLTk5DQoNCi0tDQp0byB1bnN1YnNjcmliZSBzZW5kIGEgbWVzc2FnZSB0byBuYW1lZHJvcHBlcnMtcmVxdWVzdEBvcHMuaWV0Zi5vcmcgd2l0aA0KdGhlIHdvcmQgJ3Vuc3Vic2NyaWJlJyBpbiBhIHNpbmdsZSBsaW5lIGFzIHRoZSBtZXNzYWdlIHRleHQgYm9keS4NCmFyY2hpdmU6IDxodHRwOi8vb3BzLmlldGYub3JnL2xpc3RzL25hbWVkcm9wcGVycy8+DQo=--to unsubscribe send a message to [email-masked] withthe word 'unsubscribe' in a single line as the message text body.archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 3 Jul 2009 22:04:25 +0300

> without the holddown, this approach overwhelms the parent zone's servers.

I beg to differ.  All RFC1035-compliant resolvers already do restarts,
and I'm not aware of any of them implementing these mythical
"hold-down periods" of which you speak.  Yet I don't see the net
imploding because of restart-related traffic.

> without the servfail, the question becomes, how to answer the

If the restart succeeds at reestablishing glue, then hopefully with a
NOERROR response containing the requested data.
-- 
Andreas Gustafsson, [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Fri, 03 Jul 2009 22:08:13 +0000

> Date: Fri, 3 Jul 2009 22:04:25 +0300
> From: Andreas Gustafsson <[email-masked]>
> 
> Paul Vixie wrote:
> and I'm not aware of any of them implementing these mythical "hold-down
> periods" of which you speak.  Yet I don't see the net imploding because
> of restart-related traffic.

i'm not aware of a nameserver that discards an NS RRset from cache when all
names are unreachable, in the way that i proposed.  if such a nameserver is
developed, then i do suggest that it implement the holddown i also proposed.

---

From: [email-masked] (Andreas Gustafsson)
Date: Sat, 4 Jul 2009 12:21:11 +0300

> developed, then i do suggest that it implement the holddown i also proposed.

Why should the holddown be needed in a server that implements restarts
by discarding the address-deprived NS RRset if it's not required in a
server that implements restarts by other means?  Those other means
effectively come down to keeping the NS RRset cached but ignoring it.
If it's not used, it might as well not be there - the end result is
the same, and so is the amount of traffic sent to the parent.
-- 
Andreas Gustafsson, [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Sat, 04 Jul 2009 16:33:31 +0000

> Date: Sat, 4 Jul 2009 12:21:11 +0300
> > i'm not aware of a nameserver that discards an NS RRset from cache when
> > all names are unreachable, in the way that i proposed.  if such a
> > nameserver is developed, then i do suggest that it implement the
> > holddown i also proposed.
> 
> Why should the holddown be needed in a server that implements restarts by
> discarding the address-deprived NS RRset if it's not required in a server
> that implements restarts by other means?  Those other means effectively
> come down to keeping the NS RRset cached but ignoring it.  If it's not
> used, it might as well not be there - the end result is the same, and so
> is the amount of traffic sent to the parent.

the goal of a holddown is to prevent restarts from occuring in tight loops.
that is, if a stub is asking for www.example.com every stub-to-recursive RTT
(a not-uncommon situation due to the way applications are often programmed)
and if .com's example.com delegation is correct whereas example.com's apex
NS RRset is wrong (another not-uncommon situation) and www.example.com's TTL
is zero for load balancing reasons (again, not as uncommon as i'd like), we
would see a restart on every second request for www.example.com by a stub.

with a lot of stubs doing this on a lot of names, the only protection we have
against flooding the authority servers with uselessly repeated questions that
all receive the same (correct) delegation response is some kind of holddown
in the restart logic in the recursive caching servers.  if they have no such
restart logic then they do not need a holddown, since the child-apex NS RRset
TTL will function as a holddown.

(to see a lot (billions of) of useless repeated queries to authority servers
for delegation-mostly zones, see the root servers' or the .CNO servers' query
logs.)