Thread: ns delegation, unix dig vs dnsjava dig vs dnsjava Lookup

Status: Inactive

Brought to you by: bwelling, ibauersachs

dnsjava-users

ns delegation, unix dig vs dnsjava dig vs dnsjava Lookup

From: Stefano B. <sou...@ba...> - 2007-07-17 21:49:43

Hi all,

my limited dns knowledge don't let me to reach a conclusion about this
issue.


If I ask MX servers for that domain to that server, no MX found.
--------------------
# host -t mx zunft-oberstrass.ch. 194.246.118.118
Using domain server:
Name: 194.246.118.118
Address: 194.246.118.118#53
Aliases:

zunft-oberstrass.ch has no MX record
----------------

if I ask any type I get 2 NS records
----------------
# host -a zunft-oberstrass.ch. 194.246.118.118
Trying "zunft-oberstrass.ch"
Using domain server:
Name: 194.246.118.118
Address: 194.246.118.118#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61311
;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;zunft-oberstrass.ch.           IN      ANY

;; ANSWER SECTION:
zunft-oberstrass.ch.    49631   IN      NS      ns2.nameserver.ch.
zunft-oberstrass.ch.    49631   IN      NS      ns1.nameserver.ch.

;; AUTHORITY SECTION:
zunft-oberstrass.ch.    49631   IN      NS      ns2.nameserver.ch.
zunft-oberstrass.ch.    49631   IN      NS      ns1.nameserver.ch.

Received 112 bytes from 194.246.118.118#53 in 11 ms
--------------------

If I ask the MX to one of the delegated NS I found an answer.
--------------------
# host -t mx zunft-oberstrass.ch. ns2.nameserver.ch.
Using domain server:
Name: ns2.nameserver.ch.
Address: 217.71.81.4#53
Aliases:

zunft-oberstrass.ch mail is handled by 10 mail.zunft-oberstrass.ch.
--------------------


Now, the same thing using unix dig:
----------------------
# dig @194.246.118.118 zunft-oberstrass.ch. mx

; <<>> DiG 9.3.2 <<>> @194.246.118.118 zunft-oberstrass.ch. mx
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52236
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;zunft-oberstrass.ch.           IN      MX

;; AUTHORITY SECTION:
zunft-oberstrass.ch.    49470   IN      NS      ns2.nameserver.ch.
zunft-oberstrass.ch.    49470   IN      NS      ns1.nameserver.ch.

;; Query time: 10 msec
;; SERVER: 194.246.118.118#53(194.246.118.118)
;; WHEN: Tue Jul 17 11:03:38 2007
;; MSG SIZE  rcvd: 84
--------------------------
So, no MX record found, but it returns the 2 NS like "host" did.


Now dnsjava dig command line:
--------------------
#java -cp dnsjava-2.0.3.jar dig @194.246.118.118 zunft-oberstrass.ch. mx
; java dig 0.0
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31604
;; flags: qr rd ra ; qd: 1 an: 1 au: 2 ad: 2
;; QUESTIONS:
;;      zunft-oberstrass.ch., type = MX, class = IN

;; ANSWERS:
zunft-oberstrass.ch.    3516    IN      MX      10 mail.zunft-oberstrass.ch.

;; AUTHORITY RECORDS:
zunft-oberstrass.ch.    86316   IN      NS      ns1.nameserver.ch.
zunft-oberstrass.ch.    86316   IN      NS      ns2.nameserver.ch.

;; ADDITIONAL RECORDS:
mail.zunft-oberstrass.ch.       3516    IN      A       195.129.94.130
mail.zunft-oberstrass.ch.       3516    IN      A       195.129.94.194

;; Message size: 137 bytes
;; Query time: 138 ms
--------------------
It finds the MX record!!


Can anyone explain me why there is such a difference and if this is a
result of a buggy server or where is the problem?

Is this only a difference between "recursive" client (dnsjava dig) and
"non recursive" client (unix dig)?

Thank you,
Stefano

Re: ns delegation, unix dig vs dnsjava dig vs dnsjava Lookup

From: Brian W. <bwe...@xb...> - 2007-07-17 22:02:57

On Tue, 17 Jul 2007, Stefano Bagnara wrote:

> Hi all,
>
> my limited dns knowledge don't let me to reach a conclusion about this
> issue.
>
>
> If I ask MX servers for that domain to that server, no MX found.
> --------------------
> # host -t mx zunft-oberstrass.ch. 194.246.118.118
> Using domain server:
> Name: 194.246.118.118
> Address: 194.246.118.118#53
> Aliases:
>
> zunft-oberstrass.ch has no MX record
> ----------------
>
> if I ask any type I get 2 NS records
> ----------------
> # host -a zunft-oberstrass.ch. 194.246.118.118
> Trying "zunft-oberstrass.ch"
> Using domain server:
> Name: 194.246.118.118
> Address: 194.246.118.118#53
> Aliases:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61311
> ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;zunft-oberstrass.ch.           IN      ANY
>
> ;; ANSWER SECTION:
> zunft-oberstrass.ch.    49631   IN      NS      ns2.nameserver.ch.
> zunft-oberstrass.ch.    49631   IN      NS      ns1.nameserver.ch.
>
> ;; AUTHORITY SECTION:
> zunft-oberstrass.ch.    49631   IN      NS      ns2.nameserver.ch.
> zunft-oberstrass.ch.    49631   IN      NS      ns1.nameserver.ch.
>
> Received 112 bytes from 194.246.118.118#53 in 11 ms
> --------------------
>
> If I ask the MX to one of the delegated NS I found an answer.
> --------------------
> # host -t mx zunft-oberstrass.ch. ns2.nameserver.ch.
> Using domain server:
> Name: ns2.nameserver.ch.
> Address: 217.71.81.4#53
> Aliases:
>
> zunft-oberstrass.ch mail is handled by 10 mail.zunft-oberstrass.ch.
> --------------------
>
>
> Now, the same thing using unix dig:
> ----------------------
> # dig @194.246.118.118 zunft-oberstrass.ch. mx
>
> ; <<>> DiG 9.3.2 <<>> @194.246.118.118 zunft-oberstrass.ch. mx
> ; (1 server found)
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52236
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;zunft-oberstrass.ch.           IN      MX
>
> ;; AUTHORITY SECTION:
> zunft-oberstrass.ch.    49470   IN      NS      ns2.nameserver.ch.
> zunft-oberstrass.ch.    49470   IN      NS      ns1.nameserver.ch.
>
> ;; Query time: 10 msec
> ;; SERVER: 194.246.118.118#53(194.246.118.118)
> ;; WHEN: Tue Jul 17 11:03:38 2007
> ;; MSG SIZE  rcvd: 84
> --------------------------
> So, no MX record found, but it returns the 2 NS like "host" did.
>
>
> Now dnsjava dig command line:
> --------------------
> #java -cp dnsjava-2.0.3.jar dig @194.246.118.118 zunft-oberstrass.ch. mx
> ; java dig 0.0
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31604
> ;; flags: qr rd ra ; qd: 1 an: 1 au: 2 ad: 2
> ;; QUESTIONS:
> ;;      zunft-oberstrass.ch., type = MX, class = IN
>
> ;; ANSWERS:
> zunft-oberstrass.ch.    3516    IN      MX      10 mail.zunft-oberstrass.ch.
>
> ;; AUTHORITY RECORDS:
> zunft-oberstrass.ch.    86316   IN      NS      ns1.nameserver.ch.
> zunft-oberstrass.ch.    86316   IN      NS      ns2.nameserver.ch.
>
> ;; ADDITIONAL RECORDS:
> mail.zunft-oberstrass.ch.       3516    IN      A       195.129.94.130
> mail.zunft-oberstrass.ch.       3516    IN      A       195.129.94.194
>
> ;; Message size: 137 bytes
> ;; Query time: 138 ms
> --------------------
> It finds the MX record!!
>
>
> Can anyone explain me why there is such a difference and if this is a
> result of a buggy server or where is the problem?
>
> Is this only a difference between "recursive" client (dnsjava dig) and
> "non recursive" client (unix dig)?

Something's very strange here.  Both the standard unix dig and dnsjava's 
dig default to recursive queries - this can be been by the fact that both 
answers have the RD (recursion desired) bit set.  For some reason, only 
the answer from dnsjava's dig has the RA (recursion available) bit set. 
I'm seeing the same responses, but I can't think of any good reason why 
that would happen.

I tried adding the +qr option to the standard dig, and the -q option to 
dnsjava's dig, which causes the queries to be printed as well as the 
responses, but all that shows is that the queries are identical (except 
for query id).

Brian

Re: ns delegation, unix dig vs dnsjava dig vs dnsjava Lookup

From: Stefano B. <sou...@ba...> - 2007-07-17 23:23:45

Brian Wellington ha scritto:
> On Tue, 17 Jul 2007, Stefano Bagnara wrote:
>> [...]
>> If I ask MX servers for that domain to that server, no MX found.
>> --------------------
>> # host -t mx zunft-oberstrass.ch. 194.246.118.118
>> Using domain server:
>> Name: 194.246.118.118
>> Address: 194.246.118.118#53
>> Aliases:
>>
>> zunft-oberstrass.ch has no MX record
>> ----------------
>> [...]
>> Now, the same thing using unix dig:
>> ----------------------
>> # dig @194.246.118.118 zunft-oberstrass.ch. mx
>> [...]
>> --------------------------
>> So, no MX record found, but it returns the 2 NS like "host" did.
>>
>>
>> Now dnsjava dig command line:
>> --------------------
>> #java -cp dnsjava-2.0.3.jar dig @194.246.118.118 zunft-oberstrass.ch. mx
>> [...]
>> --------------------
>> It finds the MX record!!
>>
>> Can anyone explain me why there is such a difference and if this is a
>> result of a buggy server or where is the problem?
>>
>> Is this only a difference between "recursive" client (dnsjava dig) and
>> "non recursive" client (unix dig)?
> 
> Something's very strange here.  Both the standard unix dig and dnsjava's
> dig default to recursive queries - this can be been by the fact that
> both answers have the RD (recursion desired) bit set.  For some reason,
> only the answer from dnsjava's dig has the RA (recursion available) bit
> set. I'm seeing the same responses, but I can't think of any good reason
> why that would happen.
> 
> I tried adding the +qr option to the standard dig, and the -q option to
> dnsjava's dig, which causes the queries to be printed as well as the
> responses, but all that shows is that the queries are identical (except
> for query id).
> 
> Brian

So this is more weird than I thought :-/

After more "digging" ;-) I think I found a bug in dnsjava dig. If you
call it without the full type/class specification (MX IN at the end and
some more ignored parameters) then it throws a silently caught
ArrayIndexOutOfBoundException while processing arguments. This way it
never sets the server and will use your default server :-). So I think
this is a bug you can easily fix in your dig. Once you fix that bug or
simply add "MX IN -q somethingelse" the results are different:

dnsjavadig @194.246.118.118 zunft-oberstrass.ch. MX IN -q somethingelse
------------------------------------
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41629
;; flags: rd ; qd: 1 an: 0 au: 0 ad: 0
;; QUESTIONS:
;;      zunft-oberstrass.ch., type = MX, class = IN

;; ANSWERS:

;; AUTHORITY RECORDS:

;; ADDITIONAL RECORDS:

;; Message size: 0 bytes
; java dig 0.0
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41629
;; flags: qr rd ; qd: 1 an: 0 au: 8 ad: 9
;; QUESTIONS:
;;      zunft-oberstrass.ch., type = MX, class = IN

;; ANSWERS:

;; AUTHORITY RECORDS:
ch.                     53210   IN      NS      CCTLD.TIX.ch.
ch.                     53210   IN      NS      CH1.DNSNODE.NET.
ch.                     53210   IN      NS      MERAPI.SWITCH.ch.
ch.                     53210   IN      NS      DOMREG.NIC.ch.
ch.                     53210   IN      NS      TULKU.NIC.AR.
ch.                     53210   IN      NS      SEC3.APNIC.NET.
ch.                     53210   IN      NS      DNS.PRINCETON.EDU.
ch.                     53210   IN      NS      RIP.PSG.COM.

;; ADDITIONAL RECORDS:
CH1.DNSNODE.NET.        104859  IN      A       194.146.106.10
DNS.PRINCETON.EDU.      11256   IN      A       128.112.129.15
MERAPI.SWITCH.ch.       53924   IN      A       130.59.211.10
MERAPI.SWITCH.ch.       97654   IN      AAAA    2001:620:0:0:0:0:0:5
TULKU.NIC.AR.           2628    IN      A       200.16.97.77
DOMREG.NIC.ch.          97654   IN      A       130.59.1.80
DOMREG.NIC.ch.          97654   IN      AAAA    2001:620:0:0:0:0:0:4
RIP.PSG.COM.            112056  IN      A       147.28.0.39
SEC3.APNIC.NET.         87520   IN      A       202.12.28.140

;; Message size: 418 bytes
;; Query time: 147 ms
----------------------

Too bad this is again different from the previous unix dig result :-/
so I repeated the unix dig test and now it is different than before and
is equal to dnsjava dig:

# dig +qr @194.246.118.118 zunft-oberstrass.ch. mx
-------------------------------------
; <<>> DiG 9.3.2 <<>> +qr @194.246.118.118 zunft-oberstrass.ch. mx
; (1 server found)
;; global options:  printcmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27790
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;zunft-oberstrass.ch.           IN      MX

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27790
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9

;; QUESTION SECTION:
;zunft-oberstrass.ch.           IN      MX

;; AUTHORITY SECTION:
ch.                     53084   IN      NS      DNS.PRINCETON.EDU.
ch.                     53084   IN      NS      DOMREG.NIC.ch.
ch.                     53084   IN      NS      RIP.PSG.COM.
ch.                     53084   IN      NS      SEC3.APNIC.NET.
ch.                     53084   IN      NS      MERAPI.SWITCH.ch.
ch.                     53084   IN      NS      CCTLD.TIX.ch.
ch.                     53084   IN      NS      CH1.DNSNODE.NET.
ch.                     53084   IN      NS      TULKU.NIC.AR.

;; ADDITIONAL SECTION:
CH1.DNSNODE.NET.        104733  IN      A       194.146.106.10
DNS.PRINCETON.EDU.      11130   IN      A       128.112.129.15
MERAPI.SWITCH.ch.       53798   IN      A       130.59.211.10
MERAPI.SWITCH.ch.       97528   IN      AAAA    2001:620::5
TULKU.NIC.AR.           2502    IN      A       200.16.97.77
DOMREG.NIC.ch.          97528   IN      A       130.59.1.80
DOMREG.NIC.ch.          97528   IN      AAAA    2001:620::4
RIP.PSG.COM.            111930  IN      A       147.28.0.39
SEC3.APNIC.NET.         87394   IN      A       202.12.28.140

;; Query time: 7 msec
;; SERVER: 194.246.118.118#53(194.246.118.118)
;; WHEN: Wed Jul 18 01:16:10 2007
;; MSG SIZE  rcvd: 418
-------------------------------

Now, back to my problem I have another domain that currently reproduce
the previous behaviour (even if this time the 2 dig results are equals):

dig @194.246.118.118 uudial.ch. MX IN -q somethingelse
--------------------------------
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51629
;; flags: rd ; qd: 1 an: 0 au: 0 ad: 0
;; QUESTIONS:
;;      uudial.ch., type = MX, class = IN

;; ANSWERS:

;; AUTHORITY RECORDS:

;; ADDITIONAL RECORDS:

;; Message size: 0 bytes
; java dig 0.0
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51629
;; flags: qr rd ; qd: 1 an: 1 au: 2 ad: 3
;; QUESTIONS:
;;      uudial.ch., type = MX, class = IN

;; ANSWERS:
uudial.ch.              143     IN      MX      10 mail.messaging.ch.

;; AUTHORITY RECORDS:
uudial.ch.              39743   IN      NS      dns2.agrinet.ch.
uudial.ch.              39743   IN      NS      dns1.agrinet.ch.

;; ADDITIONAL RECORDS:
mail.messaging.ch.      2249    IN      A       81.221.254.195
dns1.agrinet.ch.        3354    IN      A       81.221.250.11
dns2.agrinet.ch.        3354    IN      A       81.221.252.11

;; Message size: 152 bytes
;; Query time: 146 ms
--------------------------------

You say that dig defaults to recursive queries. Instead dnsjava Lookup
does not support recursive resolution, right?

We use dnsjava to lookup MX records for SMTP delivery: what do you think
is the behavior required by DNS+SMTP specification? Currently we simply
run the Lookup using the dnsservers configured by the user (or the one
autodiscovered by dnsjava) and take its result as is. In this
"uudial.ch." domain and 194.246.118.118 configuration the dnsjava
"Lookup" does not return the MX record: is this intended? Should we do
something different? Can you answer this or give me a pointer to some
doc I can read about?

Thank you very much!
Stefano

Re: ns delegation, unix dig vs dnsjava dig vs dnsjava Lookup

From: Brian W. <bwe...@xb...> - 2007-07-18 00:37:56

On Wed, 18 Jul 2007, Stefano Bagnara wrote:

>> Something's very strange here.  Both the standard unix dig and dnsjava's
>> dig default to recursive queries - this can be been by the fact that
>> both answers have the RD (recursion desired) bit set.  For some reason,
>> only the answer from dnsjava's dig has the RA (recursion available) bit
>> set. I'm seeing the same responses, but I can't think of any good reason
>> why that would happen.
>>
>> I tried adding the +qr option to the standard dig, and the -q option to
>> dnsjava's dig, which causes the queries to be printed as well as the
>> responses, but all that shows is that the queries are identical (except
>> for query id).
>>
> So this is more weird than I thought :-/
>
> After more "digging" ;-) I think I found a bug in dnsjava dig. If you
> call it without the full type/class specification (MX IN at the end and
> some more ignored parameters) then it throws a silently caught
> ArrayIndexOutOfBoundException while processing arguments. This way it
> never sets the server and will use your default server :-). So I think
> this is a bug you can easily fix in your dig. Once you fix that bug or
> simply add "MX IN -q somethingelse" the results are different:

Good catch.  Yes, that looks like a problem.

> Now, back to my problem I have another domain that currently reproduce
> the previous behaviour (even if this time the 2 dig results are equals):
>
> [snip]
>
> You say that dig defaults to recursive queries. Instead dnsjava Lookup
> does not support recursive resolution, right?

The terminology you're using here is a bit confusing.  The standard unix 
dig, dnsjava's dig program, and the dnsjava Lookup class all behave the 
same way - they set the recursion desired bit on queries, meaning that 
they are requesting that the server perform a recursive lookup.  None of 
them performs recursive resolution themselves.

> We use dnsjava to lookup MX records for SMTP delivery: what do you think
> is the behavior required by DNS+SMTP specification? Currently we simply
> run the Lookup using the dnsservers configured by the user (or the one
> autodiscovered by dnsjava) and take its result as is. In this
> "uudial.ch." domain and 194.246.118.118 configuration the dnsjava
> "Lookup" does not return the MX record: is this intended? Should we do
> something different? Can you answer this or give me a pointer to some
> doc I can read about?

I don't know what 194.246.118.118 is, but when I query it, it's not doing 
recursion.  dnsjava's Lookup class is a stub resolver, so it should only 
be sending queries to servers that perform recursion.  If I instead send 
the query to a server that does perform recursion, I get the desired MX 
record.

Brian

Re: ns delegation, unix dig vs dnsjava dig vs dnsjava Lookup

From: Stefano B. <sou...@ba...> - 2007-07-18 07:52:03

Brian Wellington ha scritto:
>> We use dnsjava to lookup MX records for SMTP delivery: what do you think
>> is the behavior required by DNS+SMTP specification? Currently we simply
>> run the Lookup using the dnsservers configured by the user (or the one
>> autodiscovered by dnsjava) and take its result as is. In this
>> "uudial.ch." domain and 194.246.118.118 configuration the dnsjava
>> "Lookup" does not return the MX record: is this intended? Should we do
>> something different? Can you answer this or give me a pointer to some
>> doc I can read about?
> 
> I don't know what 194.246.118.118 is, but when I query it, it's not
> doing recursion.  dnsjava's Lookup class is a stub resolver, so it
> should only be sending queries to servers that perform recursion.  If I
> instead send the query to a server that does perform recursion, I get
> the desired MX record.

Maybe I'm confusing iterative vs recursive terms.

I tried googling this but I didn't find an answer:

is a server allowed to reply non-recursively to a recursive question?

what does a client should (have to) do when a server replies without the
"ra" flag?

Should we keep resolving the data to the NS server received?

If so, can you suggest an approach to the problem using dnsjava?

Would this behavior be defined "iterative" resolution or iterative vs
recursive both describe only server side resolution?

What do other other clients do wrt non recursive servers?

Thank you again,
Stefano

Re: ns delegation, unix dig vs dnsjava dig vs dnsjava Lookup

From: Brian W. <bwe...@xb...> - 2007-07-18 09:06:44

On Wed, 18 Jul 2007, Stefano Bagnara wrote:

> Brian Wellington ha scritto:
>>> We use dnsjava to lookup MX records for SMTP delivery: what do you think
>>> is the behavior required by DNS+SMTP specification? Currently we simply
>>> run the Lookup using the dnsservers configured by the user (or the one
>>> autodiscovered by dnsjava) and take its result as is. In this
>>> "uudial.ch." domain and 194.246.118.118 configuration the dnsjava
>>> "Lookup" does not return the MX record: is this intended? Should we do
>>> something different? Can you answer this or give me a pointer to some
>>> doc I can read about?
>>
>> I don't know what 194.246.118.118 is, but when I query it, it's not
>> doing recursion.  dnsjava's Lookup class is a stub resolver, so it
>> should only be sending queries to servers that perform recursion.  If I
>> instead send the query to a server that does perform recursion, I get
>> the desired MX record.
>
> Maybe I'm confusing iterative vs recursive terms.
>
> I tried googling this but I didn't find an answer:
>
> is a server allowed to reply non-recursively to a recursive question?

Yes.  There is no such thing as a recursive question - there is a question 
where recursion is desired.  There's no way to require recursion.

> what does a client should (have to) do when a server replies without the
> "ra" flag?

There's nothing a client can do.  A client which is incapable of 
performing recursion itself should not be configured to point at servers 
which do not perform recursion.  Anything else is a configuration error on 
the client.

> Should we keep resolving the data to the NS server received?
>
> If so, can you suggest an approach to the problem using dnsjava?

Continuing the resolution would be the correct thing to do if you were 
writing a name server.  From the context of a client wishing to lookup MX 
records, I believe the right thing to do is simply fail.

> Would this behavior be defined "iterative" resolution or iterative vs
> recursive both describe only server side resolution?

I'm not really sure how iterative resolution would differ from recursive 
resolution.  There are basically two kinds of resolvers - full resolvers 
and stub resolvers.  A full resolver would use the complete resolution 
algorithm, talking to authoritative name servers and following NS records. 
A stub resolver would ask a full resolver to do the recursion for it.

Pretty much every client application uses a stub resolver.  It's possible 
to have a full resolver that's not part of a caching name server, but I 
don't know of any.

> What do other other clients do wrt non recursive servers?

They would generally fail to perform the desired lookups.

Brian