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

From: Keith Moore <[email-masked]>
Date: Tue, 7 Jan 2003 09:31:05 -0500

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.

1. use of SRV to implement getservbyname

It is not appropriate to use SRV lookups to implement getservbyname().
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.  

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.

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).

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.

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.

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.

if you want "disconnected" servers to respond to queries for FQDNs then
those servers need to be authoritative for those FQDNs, and they need
to produce results which are consistent with the other servers for those
FQDNs.  if some of those servers are on isolated networks and others are
on the global internet, this is not a problem as long as the rules for
serial numbers are followed.  DNS can cope with different servers 
returning different results as long as those servers have different
serial numbers and single-copy serializability is maintained.

If a host which is authoritative for one or more FQDNs that are assigned
to a host migrates from one network to another, or for whatever reason
acquires a new address and/or needs to change its RRs, that host can update
its RRs on its stub server and increment the serial # for that zone.  If 
and when the host has connectivity to the (other) advertised servers for 
that zone, it should update those servers.  But even if the host finds itself
on an isolated network there is no problem with its updating its own zone
and incrementing the serial number, perhaps multiple times, as long as it
updates the slave servers whenever it is possible to do so.  Of course there
are operational concerns associated with advertising RRs that point to
addresses that are not reachable, but we generally expect protocols to be
robust when hosts are not reachable anyway.  Appropriate assignment of TTLs
is the best solution here, and the host is in the best position to know 
whether its RRs should have long or short TTLs (e.g. whether it is stable
or nomadic).

--
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 10:49:35 -0800 (PST)

% 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. 
	
% 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?
	
% 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. 

% 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.

% 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.

% 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.  

% 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.

% if you want "disconnected" servers to respond to queries for FQDNs then
% those servers need to be authoritative for those FQDNs, and they need
% to produce results which are consistent with the other servers for those
% FQDNs.  if some of those servers are on isolated networks and others are
% on the global internet, this is not a problem as long as the rules for
% serial numbers are followed.  DNS can cope with different servers 
% returning different results as long as those servers have different
% serial numbers and single-copy serializability is maintained.

	Yes.

% If a host which is authoritative for one or more FQDNs that are assigned
% to a host migrates from one network to another, or for whatever reason
% acquires a new address and/or needs to change its RRs, that host can update
% its RRs on its stub server and increment the serial # for that zone.  If 
% and when the host has connectivity to the (other) advertised servers for 
% that zone, it should update those servers.  But even if the host finds itself
% on an isolated network there is no problem with its updating its own zone
% and incrementing the serial number, perhaps multiple times, as long as it
% updates the slave servers whenever it is possible to do so.  Of course there
% are operational concerns associated with advertising RRs that point to
% addresses that are not reachable, but we generally expect protocols to be
% robust when hosts are not reachable anyway.  Appropriate assignment of TTLs
% is the best solution here, and the host is in the best position to know 
% whether its RRs should have long or short TTLs (e.g. whether it is stable
% or nomadic).

	The model here is that the FQDN does not change based on location in
	the topology. The dynamic update features existant in todays protocols
	are largely intact from the old work.  It is true that dynamic dns
	work has evolved since this experiment was run.

% --
% 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/>
% 

-- 
--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).

---

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

On Mon, 13 Jan 2003 10:49:35 -0800 (PST)

> 	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.

> 	Where your references to "it" is the call  getservbyname() correct

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

> % up "well known ports" independent of domain is overloading the SRV RR type.

I strongly and emphatically disagree.

> 	network lookups was done as proof of concept and to explore the

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

> 	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.  

> 	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.

> 	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

---

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

---

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

> 	do. and wrt SRV, we defined how SRV is used for DNS.               

silly me.  I thought RFC 2782 defined how SRV was used for DNS, and that
the RFCs for applications defined which port numbers they use.

>From RFC 2782:

Applicability Statement

   In general, it is expected that SRV records will be used by clients
   for applications where the relevant protocol specification indicates
   that clients should use the SRV record. Such specification MUST
   define the symbolic name to be used in the Service field of the SRV
   record as described below. It also MUST include security
   considerations. Service SRV records SHOULD NOT be used in the absence
   of such specification.

--
Keith Moore                              http://www.cs.utk.edu/~moore/
27 February 1933                                     11 September 2001

---

From: Paul Vixie <[email-masked]>
Date: Mon, 13 Jan 2003 20:35:17 +0000

i thought i'd let everybody know that after some deep talks with
stuart cheshire over at apple, i am withdrawing my support and
co-authorship of the DISCOVER draft.