Subject: Re: commens on draft-dnsext-opcode-discover-01.txt

From: Keith Moore <[email-masked]>
Date: Mon, 13 Jan 2003 14:09:34 -0500

On Mon, 13 Jan 2003 10:49:35 -0800 (PST)
Bill Manning <[email-masked]> wrote:

> % Note: I'm reading this as if it's a draft protocol specification
> % rather than as if it's intended as an informational or experimental
> % document.  Even if the latter is intended, some amount of clarification
> % seems in order.
> 
> 
> 	Thanks for your comments. Note that it is clearly -NOT-
> 	expected to be a draft protocol specification.  This is 
> 	the documentation of a set of experiments that were run in
> 	1998/1999 and some of the lessons learned.
> 
> % 1. use of SRV to implement getservbyname
> % 
> % It is not appropriate to use SRV lookups to implement getservbyname().
> 
> 	Why?  Its not forbidden and it can be made to work. 

a) it's changing the behavior of existing applications that expect
   well-known port numbers.
 
b) it's violating the SRV RFC, which states that each application needs
   to define how SRV is used.

> % This would change the behavior of nearly every protocol on the Internet
> % without considering the impact on the protocol or applications that use
> % it.  Use of SRV MUST be determined on a per-protocol or per-application
> % basis.  
> 
> 	Where your references to "it" is the call  getservbyname() correct

yes, but it's also true for SRV in general.

> % Furthermore SRV was intended to delegate services for specific DNS domains,
> % and getservbyname() doesn't provide a way to input the domain for which
> % the SRV query is being made.  Trying to use SRV as a generic way to look
> % up "well known ports" independent of domain is overloading the SRV RR type.
> 
> 	Not really. 

I strongly and emphatically disagree.

> % That,and trying to use the network to look up constants never was a good
> % idea, not in the context of YP/NIS or anything else.  I've seen too many
> % programs fail because getservbyname() was implemented using NIS, and the
> % NIS server was down.  It's not as if protocol implementors don't know what
> % port numbers to use anyway.  If it's reasonable for a protocol implementation 
> % to include string constants like "MAIL FROM" or "POST", then it's reasonable
> % for that protocol implementation to include integer constants like htons(25)
> % or htons(80).
> 
> 	The experiment made the presumption that the constants being lookedup
> 	were available from the system being queried. Extrapolation to over
> 	network lookups was done as proof of concept and to explore the
> 	ramifications thereof.

I doubt your experiments were of sufficient scale to show the problems.

> 
> % 2. under section 2, "method", "Example usage for gethostby{name,addr}-style 
> % requestors:"
> % 
> % it's not at all clear why "the zone name of the enclosing in-addr.arpa, 
> % ip6.int, or ip6.arpa domain" is relevant to an A or AAAA query (as in
> % gethostbyname ) or why queries for a particular NAME should only be sent
> % to servers that are authoritative for the enclosing ADDRESS domain.
> % 
> % Is this really what is intended or is it just poor wording?  It reads
> % as if you're trying to make the results of DNS lookups vary according
> % to location.
> 
> 	Correct. the results were to vary based on location/topology.

well, that's another lousy idea.  many applications depend on DNS names
producing consistent results from multiple locations in the Internet.  

> % 3. same section
> % 
> % "Once one learns a host's FQDN by the above means, repeat the process
> % for discovering the closest enclosing authoritative server of such
> % local name."
> % 
> % the idea that a host has "a" FQDN seems anachronistic at best. hosts have
> % zero or more addresses assigned to them at any particular time; each
> % address may be associated with zero or more FQDNs.   the address-to-host
> % bindings may be short- or long-lived.  in general there is no way that the
> % network can be expected to know whether a particular FQDN is any kind of 
> % "distinguished name" for a host.  the host has to be configured to know
> % this on its own.
> 
> 
> 	the host (knowing its FQDN) responds to requests by sending
> 	its FQDN.  One of the preconditions of the experiment is that
> 	each participating node is "imprinted" with an FQDN and some
> 	key material that is tied to that FQDN.  

again the idea that a host has "a" FQDN seems anachronistic.
if you can generalize this to something like "a server on a host may be  
made authoritative for zero or more FQDNs"
then it might be more useful.

> 
> % 4. regarding disconnected networks
> % 
> % NO server -- whether multicast or not, whether using DISCOVER or not, 
> % whether using the DNS port or not, whether using the DNS protocl or not --
> % should be answering queries as if it were authoritative for any DNS zone
> % for which that server is not authoritative.  The result will inevitiably
> % be that such results are leaked into, and mixed with, results from
> % legitimate DNS servers.  a network which appears isolated to one host
> % in a network may not be isolated to another host in the same network.
> 
> 
> 	Perhaps we should include the TBDS final report in the references.
> 	The experiment presumes that each node is authoritative for its
> 	point in the DNS heirarchy. This draft does not presume to answer
> 	authoritativly for any part of the DNS. It presumes that the caching
> 	servers will cache information they receive, just as happens now.

some of additional context would help the draft immensely.
stating your goals, assumptions, the constraints you imposed, the 
limitations of your work, all seem appropriate for a description of an 
experiment.

Keith

--
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: Bill Manning <[email-masked]>
Date: Mon, 13 Jan 2003 11:37:43 -0800 (PST)

% > 	Thanks for your comments. Note that it is clearly -NOT-
% > 	expected to be a draft protocol specification.  This is 
% > 	the documentation of a set of experiments that were run in
% > 	1998/1999 and some of the lessons learned.
% > 
% > % 1. use of SRV to implement getservbyname
% > % 
% > % It is not appropriate to use SRV lookups to implement getservbyname().
% > 
% > 	Why?  Its not forbidden and it can be made to work. 
% 
% a) it's changing the behavior of existing applications that expect
%    well-known port numbers.
%  
% b) it's violating the SRV RFC, which states that each application needs
%    to define how SRV is used.

	it was an experiment. changing behaviour is one thing that experiments
	do. and wrt SRV, we defined how SRV is used for DNS.               
	
% > % the SRV query is being made.  Trying to use SRV as a generic way to look
% > % up "well known ports" independent of domain is overloading the SRV RR type.
% > 
% > 	Not really. 
% 
% I strongly and emphatically disagree.

	thats allowed. 

% > 	The experiment made the presumption that the constants being lookedup
% > 	were available from the system being queried. Extrapolation to over
% > 	network lookups was done as proof of concept and to explore the
% > 	ramifications thereof.
% 
% I doubt your experiments were of sufficient scale to show the problems.

	that kind of presumes a single suite of problems to be shown.
	we found several and identified ways to overcome some of them.

% > 	Correct. the results were to vary based on location/topology.
% 
% well, that's another lousy idea.  many applications depend on DNS names
% producing consistent results from multiple locations in the Internet.  

	your concept of "lousy" ideas may even be relevent.
	  
% > 	the host (knowing its FQDN) responds to requests by sending
% > 	its FQDN.  One of the preconditions of the experiment is that
% > 	each participating node is "imprinted" with an FQDN and some
% > 	key material that is tied to that FQDN.  
% 
% again the idea that a host has "a" FQDN seems anachronistic.
% if you can generalize this to something like "a server on a host may be  
% made authoritative for zero or more FQDNs"
% then it might be more useful.

	so set the wayback machine for 1998 and we'll be happy to redo
	the work.

% > 	Perhaps we should include the TBDS final report in the references.
% > 	The experiment presumes that each node is authoritative for its
% > 	point in the DNS heirarchy. This draft does not presume to answer
% > 	authoritativly for any part of the DNS. It presumes that the caching
% > 	servers will cache information they receive, just as happens now.
% 
% some of additional context would help the draft immensely.
% stating your goals, assumptions, the constraints you imposed, the 
% limitations of your work, all seem appropriate for a description of an 
% experiment.

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).