1034 Resolver Algo Question

[Jonathan de Boyne Pollard]

WS> It does not say anything about saving the CNAME rr anywhere.

This is but one example of 5.3.3 glossing over things.

WS> You change the Sname to the canonical name in the RR and start at
WS> step 1 again.  What happens to the CNAME we just processed?  Lost?

It should be appended to the alias chain in the response that will 
eventually be sent to the original client.  (Note "appended".  Pretty 
much all DNS clients assume that the resource records comprising the 
client-side alias chain in a response are actually listed in order, 
although RFC 1034 nowhere actually says that this is the case, and only 
even implies it by the operation of the 4.3.2 algorithm.)

WS> Or do you keep building an answer section in a tmp reply structure
WS> until done or error?

Another thing that 5.3.3 glosses over is what to do in the case where 
tracking down a client-side alias chain causes query resolution to take 
so long that the earlier cached "CNAME" resource records expire before 
the end of the chain is found.  (Yes, people _have_ been known to put 
exceedingly low TTLs on "CNAME" resource record sets.)

On reasonable design is to entirely throw out the 5.3.3 notion of 
passing response data through, and to employ a design where responses 
are _always_ constructed _solely_ from what is in the cache.  Response 
processing then becomes (in précis):

1. Perform triage to determine the _form_ of the response (i.e. complete 
answer with a non-empty resource record set, complete answer with an 
empty resource record set, complete answer with a "no such name" error, 
or partial answer ending in a referral).  Note that out-of-bailiwick 
resource records will affect form.
2. Collect the _in-bailiwick_ resource records into resource record sets 
and add them to the cache.
3. Add any _in-bailiwick_ empty resource record sets and "no such name" 
errors to the cache, too.
4. Attempt to construct a complete answer to the original question, from 
scratch, using only cached data.
5. If the complete answer could not be constructed, issue a further back 
end query for the data that are still missing, taking into account as 
appropriate any new delegation information that may just have been 
received and cached and issuing any additional queries that may be 
needed to obtain missing delegation information.