resolver's behavior

[Kevin Darcy]

Frank Y.F. Luo wrote:

>Let me ask you guys a similar question:
>
>a NS only allows authoritative query (that means recursive query turned
>off).
>
>What if I configure a client ( Windows, Mac OS, Solaris, ....) to use this
>NS and do a non-authoritative query, what will happen? 
>
There's no such thing as a "non-authoritative query". I think you mean 
non-recursive query.

When you query a nameserver/resolver non-recursively, then the only data 
you'll get as an answer will be a) data from zones for which the 
nameserver is authoritative, and/or b) data which happens to be in the 
resolver cache from an earlier query for which recursion was performed. 
Note that if recursion is turned off *completely* for the target 
instance, i.e. it does not perform any kind of resolver function, there 
will be nothing in its cache, so only the (a) category (authoritative 
data) applies.

>I know the first query will be "qr" - recursive preferred, 
>
Um, no, QR means "query response". All DNS responses have QR set. That 
flag distinguishes a query from a query response and has nothing to do 
with recursion _per_se_. RD (recursion desired) is how recursion gets 
requested from the client side, and RA (recursion available) in the 
response is how the server side signals its willingness or unwillingness 
to comply with the request for recursion.

>but since recursive query turned
>off, the NS will return the root NS will be returned to the client. 
>
The root NS in the Authority Section basically means "I don't know the 
answer, I'm not going to recurse for the answer, go figure it out 
yourself, and here's some root-NS information to get you started, good 
luck".

>What is
>supposed to happen at this time to client? Will client follow that to query
>root NS? 
>
If the client is a dumb "stub resolver", then a root-NS referral 
basically results in the query failing.

If the client has some iterative smarts, it probably wouldn't have made 
that query in the first place to a nameserver that is/was not 
authoritative for the zone. In the absence of some sort of explicit 
"forwarding" or "stub" configuration, it would only send queries 
(non-recursive) to a particular nameserver if it believed, based on 
following the delegation chain, that the nameserver was authoritative 
for the relevant zone, or could give a referral that would lead the 
resolver closer to a definitive answer. "Lame" delegation, a 
configuration error where a delegation record points to a nameserver 
which is not in fact authoritative for a particular zone, is of course 
possible, but it's the exception, not the rule.

>Is there any difference in different resolver implementation as you know?
>
Well, yes, the major distinction is between a "stub" resolver and a 
"full-service" resolver that is capable of iterative resolution and/or 
implements caching. Note that named from the BIND distribution can 
function as either a "full-service" resolver or an authoritative 
nameserver, or both, if it is configured to perform both roles 
simultaneously. Other DNS packages, e.g. djbdns, break out those 
functions into separate programs.

What is it, exactly, that you are trying to accomplish, Frank? If you're 
just trying to educate yourself, there are books and other materials 
that you should probably be reading, e.g. the _DNS_and_BIND_ book from 
O'Reilly. If you have a specific problem that you are trying to solve, 
then please tell us what it is.

                                                                         
                                                   - Kevin