Subject: Re: [question]What is an accurate meaning of "client" in RFC2181?

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Feb 2006 23:18:53 +1100

> Hi all,
> 
> I have a question regarding the word "client" in RFC2181.
> 
> For example, section 5.2 says,
> 
> -------------------
>    Should a client receive a response containing RRs from an RRSet with
>    differing TTLs, it should treat this as an error.  If the RRSet
>    concerned is from a non-authoritative source for this data, the
>    client should simply ignore the RRSet, and if the values were
>    required, seek to acquire them from an authoritative source.  Clients
>    that are configured to send all queries to one, or more, particular
>    servers should treat those servers as authoritative for this purpose.
>    Should an authoritative source send such a malformed RRSet, the
>    client should treat the RRs for all purposes as if all TTLs in the
>    RRSet had been set to the value of the lowest TTL in the RRSet.  In
>    no case may a server send an RRSet with TTLs not all equal.
> -------------------
> 
> In this paragraph, the word "clinet" appears four times.
> Does all of these "client" mean just only client(simple resolver client)? 
> Or, does these "cleint" mean include the server acting as client for the purp
> oses of recursive query resolution?

	It also means the resolver in the nameserver.

	RRset with differing TTLs was a common indication that the
	answer had come from a nameserver that had merged RRsets
	or had got a answer from another nameserver that had merged
	RRsets.

> I think that this word "client" is unclear.

	The DNS is a client / server protocol.  A recursive server
	has a client component that iterates.
 
> There is a similar problem also in section 9. 
> ------------------
> 
>    Where TC is set, the partial RRSet that would not completely fit may
>    be left in the response.  When a DNS client receives a reply with TC
>    set, it should ignore that response, and query again, using a
>    mechanism, such as a TCP connection, that will permit larger replies.
> ------------------
> 
> What do you think?

	Again this is clear.  If you ask a question over UDP and
	get TC in the response you need to re-ask the question using
	TCP.  The problem then becomes what do you do when you get
	TC over TCP? 

	Mark
 
> Best Regards,
> -- 
> *************************************
> Hideshi Enokihara
> IPv6 Business
> Network & Software Development Dept.
> Yokogawa Electric Corporation
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Hideshi Enokihara <[email-masked]>
Date: Thu, 2 Feb 2006 22:10:03 +0900

Thank you for your reply.

The purpose of this question is to want to avoid the confusion of the 
meaning of the word "client" and "resolver".

RFC2308 that you wrote doesn't use the word "client". 
The word "resolver" is clearly used instead of "client".

I personally thought that the word "resolver" include "Recursion server" and "Client", and the word "cleint" is just simple client.

Can I think that "Clinet" and "Resolver" are the same meanings in RFC?

Best Regards,

On Thu, 02 Feb 2006 23:18:53 +1100

---

From: Paul Vixie <[email-masked]>
Date: Thu, 02 Feb 2006 14:50:54 +0000

i believe that the terms "client" and "server" are inadequate to describe
the roles of the various protocol agents in DNS, and as in RFC 2136, i
suggest the terms "initiator" and "responder" instead.  the the parts of
RFC 2181 which you've quoted here, "client" really means "initiator".  the
DNS protocol specification must be understood in terms of messages --
their format and meaning.  two messages make up a transaction, and each
transaction is initiated by some protocol agent and responded to by others.