rfc1034 3rd step question.

[Barry Margolin]

In article <c8bk3k$2tlr$1 at sf1.isc.org>,
 "William Stacey" <staceyw at mvps.org> wrote:

> > You seem to have missed step 3b:
> >          b. If a match would take us out of the authoritative data,
> >             we have a referral.  This happens when we encounter a
> >             node with NS RRs marking cuts along the bottom of a
> >             zone.
> >             Copy the NS RRs for the subzone into the authority
> >             section of the reply.  Put whatever addresses are
> >             available into the additional section, using glue RRs
> >             if the addresses are not available from authoritative
> >             data or the cache.  Go to step 4.
> > The sub1.test.com NS record means that anything.sub1.test.com is out of
> > this authoritative zone
> 
> True.  But aren't we still currently at label "www.sub1.test.com"?

Yes, we are.  But the NS record for sub1.test.com means that anything in 
this subdomain "would take us out of the authoritative data."

>  We have
> not looped yet to search for lable "sub1.test.com" to find the NS records?

You have to look for them anyway, to determine where the zone cuts are.

> Am I still missing something basic?  Do you march down the labels toward the
> root looking for NS records 3b before starting again looking for
> "*.sub1.test.com" in 3c.?  It would be cool if some kind sole could do a
> pseudo code like in rfc 2136 for algorithum and the resolver logic.  I have
> worked on it a bit for education purposes, but get stuck on some of these
> questions.  Cheers!

Once you delegate a subdomain to another server, you can't have any 
authoritative records within it (except for glue records).  So there's 
no point in searching for *.sub1.test.com when we're not authoritative 
for the subdomain.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***