Subject: mDNS needs something like this

From: Bill Manning <[email-masked]>
Date: Sun, 3 Jun 2001 06:04:52 -0700 (PDT)

With thanks to the moderator for correcting an old problem, here
	is something for the current mDNS crowd to consider.  It was useful
	in the first iteration of mDNS from a couple years ago.
	-------------------------------------------------------------

Individual Submission                                      Bill Manning 
draft-opcode-discover-01.txt                                        ISI 
                                                            03 Jun 2001

                         The DISCOVER opcode 

This document is an Internet-Draft and is NOT offered in accordance with 
Section 10 of RFC2026, and the author does not provide the IETF with any 
rights other than to publish as an Internet-Draft. This document is a
submission to the domain name system extentions (DNSEXT) working group
of the Internet Engineering Task Force (IETF). Comments may be submitted
to the working group mailing list at "[email-masked]" or the 
author.  Distribution of this memo is unlimited.

Internet-Drafts are working documents of the Internet Engineering Task 
Force (IETF), its areas, and its working groups.  Note that other groups 
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and 
may be updated, replaced, or obsoleted by other documents at any time.  It 
is inappropriate to use Internet-Drafts as reference material or to cite 
them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

This work was funded under DARPA grant: F30602-99-1-0523

0. Abstract

   The QUERY opcode in the DNS is designed for unicast. With the 
   development of multicast capabilities in the DNS, it is desireable
   to have a more robust opcode for server interactions.

1. DISCOVER works like QUERY except:

        1. it can be sent to a broadcast or multicast destination (QUERY
           isn't defined for non-unicast, and arguably shouldn't be.)

        2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
           tuples. Future work could augment this structure as follows:
	  <QNAME=service,QTYPE=SRV>

        3. if QDCOUNT==0 then only servers willing to do recursion should
           answer. Other servers must silently discard the DISCOVER request.

        4. if QDCOUNT!=0 then only servers who are authoritative for the
           zones named by some QNAME should answer.

        5. responses may echo the request's Question section or leave it blank.

        6. responses have "normal" Answer, Authority, and Additional sections.
	   e.g. the response is the same as that to a QUERY.

Usage for gethostby{name,addr}-style requestors:

        Compute the zone name of the enclosing in-addr.arpa or ip6.int domain.

        DISCOVER whether anyone in-scope is authoritative for this zone.

                If so, query these authoritative servers for local
                in-addr/ip6 names.

        If not, DISCOVER whether there are recursive servers available.

                If so, query these recursive servers for local
                in-addr/ip6 names.

	So, a node will issue a multicast request with the DISCOVER opcode at 
	some particular multicast scope.  Then determine, from the replies, 
	whether there are any DNS servers which are authoritative (or support 
	recursion) for the zone.

        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.

        Cache all NS and A data learned in this process, respecting TTL's.

Usage for SRV requestors:

        Do the gethostbyaddr() and gethostbyname() on one's own LAN-local
        address, using the above process.

        Assume that the closest enclosing zone for which an authority server
        answers an in-scope DISCOVER packet is "this host's parent domain".

        Compute the SRV name as _service._transport.*.parentdomain.
	
	This is a change to the definition as defined in RFC 1034. 
	A wildcard label ("*") in the QNAME used in a DNS message with 
  	opcode DISCOVER SHOULD be evaluated with special rules.  The 
  	wildcard matches any label for which the DNS server data is
 	authoritative.  For example 'x.*.example.com.' would match 
  	'x.y.example.com.' and 'x.yy.example.com.' provided that the
  	server was authoritative for 'example.com.'  In this particular
	case, we suggest the follwing considerations be made:

   getservbyname() can be satisfied by issuing a request with 
     this computed SRV name.  The servent structure can be 
     populated by values returned from a request as follows:

        s_name    The name of the service, "_service" without the 
                  preceding underscore.
        s_aliases The names returned in the SRV RRs in replies
                  to the query.
        s_port    The port number in the SRV RRs replies to the
                  query.  If these port numbers disagree - one
                  of the port numbers is chosen, and only those
                  names which correspond are returned.
        s_proto   The transport protocol from named by the 
                  "_transport" label, without the preceding 
                  underscore.

        Send SRV query for this name to discovered local authority servers.

Usage for disconnected networks with no authority servers:

        Hosts should run a "stub server" which acts as though its FQDN is a
        zone name.  Computed SOA gives the host's FQDN as MNAME, "." as the
        ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
        and the other timers.  Computed NS gives the host's FQDN.  Computed
        glue gives the host's LAN-local address. Or Hosts may run a
	"DNS stub server" which acts as though its FQDN is a zone name.  The 
	rules governing the behavior of this stub server are given elsewhere 
	[1] [2].

        Such stub servers should answer DISCOVER packets for its zone, and
        will be found by the iterative "discover closest enclosing authority
        server" by DISCOVER clients, either in the gethostbyname() or SRV
        cases described above.  Note that stub servers only answer with
        zone names which match QNAME's, not with zone names which are owned
        by QNAME's.

The only deviation from the DNS model is that a host (like, say, a printer
offering LPD services) has a DNS server which answers authoritatively for
something which hasn't been delegated to it.  However, the only way that
such DNS servers can be discovered is with a new opcode, DISCOVER, which
is explicitly defined to discover undelegated zones for tightly scoped
purposes.  Therefore this isn't officially a violation of DNS's coherency
principles.

  The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119

3. IANA Considerations

	As a new opcode, the IANA will need to assign a numeric value
	for the memnonic.  Test implementations have used the numeric
	value 6, being the next one available after 5, for update.

4. Security Considerations

         No new security considerations are known to be introduced. Using
	multicast for service discovery has the potential for denial of 
	service.

5. Attribution:
	
	This material was generated in discussions on the mdns mailing list
hosted by Zocalo in March 2000. Paul Vixie crystalized the concepts... 
Stuart Cheshire, Bill Woodcock, Erik Guttman and  were active contributors.

6. Author's Address

   Bill Manning
   PO 12317
   Marina del Rey, CA. 90295
   +1.310.322.8102
   [email-masked]

7. References

[1] draft-ietf-dnsext-mdns-00.txt
[2] draft-manning-dnsext-mdns-00.txt

-------------------------------------------------------------------------------

--bill

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Paul A Vixie <[email-masked]>
Date: Sun, 03 Jun 2001 09:42:04 -0700

> Subject: mDNS needs something like this

agreed.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 05 Jun 2001 22:35:02 -0400

[ ack -- rb ]

At 09:04 AM 6/3/2001, Bill Manning wrote:-
>author.  Distribution of this memo is unlimited.

It has been pointed out to me that the above copyright is not in
compliance with section 10 in RFC2026 thus no IETF working groups
can consider this document.

Moderators, please do not approve any messages related to this draft on
namedroppers until the draft has been reissued with a copyright permitted
under section 10 in RFC2026.

This note does not reflect in any way on any technical merits of the
document.

         thanks
         Olafur

---

From: Thomas Narten <[email-masked]>
Date: Wed, 06 Jun 2001 11:14:58 -0400

> can consider this document.

To clarify a bit.

The above boilerplate is contradictory. On the one hand, the submitter
does not grant the IETF/WG any rights to excerpt text, modify it,
etc., as is the norm in IETF WGs. The only right granted is to publish
as an ID.  On the other hand, the above text says this document is a
submission to the WG. The WG shouldn't be accepting submissions that
it has no change control over. That is not the IETF way.

Note that it is possible (and appropriate) to submit IDs with a "only
publish as an ID" type clause in limited circumstances. For example,
there may be times when an outside standards body wishes to make
available one of its internal documents for the IETF to look at, but
there is no intention that the document will be published as an RFC or
modified in any way by the IETF, and the originating standards body
wishes to retain full control over the text.

However, draft-ymbk-opcode-discover-01.txt would not appear to be one
of those types of documents.

Finally, the above boilerplate also (by design) sidesteps the question
of whether all the rules in Section 10 of RFC 2026 are applicable and
are being followed. Again, avoiding that question is not appropriate
for a document intended to be a WG contribution.

If this document is really intended as a legitimate submission to a
WG, it should be resubmitted with appropriate boilerplate.

Comments/disagreements on this would best be taken to poisson, as the
issues have nothing at all to do with the content of the document.

Thomas