kcd at daimlerchrysler.com
Tue Apr 25 22:24:16 UTC 2006
Frank Y.F. Luo wrote:
>Let me ask you guys a similar question:
>a NS only allows authoritative query (that means recursive query turned
>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
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
>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
>supposed to happen at this time to client? Will client follow that to query
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.
More information about the bind-users