Multicast DNS and Multicast DNS Service Discovery
Stuart Cheshire <cheshire@apple.com> Fri, 20 July 2001 12:51 UTC
Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18963 for <dnsext-archive@lists.ietf.org>; Fri, 20 Jul 2001 08:51:24 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.31 #1) id 15NZRw-00068S-00 for namedroppers-data@psg.com; Fri, 20 Jul 2001 05:32:08 -0700
Received: from h-135-207-10-122.research.att.com ([135.207.10.122] helo=roam.psg.com) by psg.com with esmtp (Exim 3.31 #1) id 15NZRv-00068L-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 05:32:08 -0700
Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NZRq-0000b2-00 for namedroppers@ops.ietf.org; Fri, 20 Jul 2001 08:32:02 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: Stuart Cheshire <cheshire@apple.com>
To: namedroppers@ops.ietf.org
Subject: Multicast DNS and Multicast DNS Service Discovery
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Message-Id: <E15NZRw-00068S-00@psg.com>
Date: Fri, 20 Jul 2001 05:32:08 -0700
Content-Transfer-Encoding: 7bit
Last week I submitted two Internet Drafts, one proposing how I think Multicast DNS should work, and a second proposing how to do Service Discovery over Multicast DNS (or indeed conventional unicast DNS). The primary difference between my draft and "draft-ietf-dnsext-mdns-01.txt" is the philosophy about how subdomains of the "local.arpa." domain are delegated. The "draft-ietf..." document proposes that hosts running Multicast DNS Responders each assert an SOA record, thereby claiming to be the sole authority for their own little zone within the "local.arpa." domain. That approach makes it difficult for different hosts to manage two or more resource records with the same name, a feature that has some benefits. My draft proposes that subdomains of the "local.arpa." domain can never be delegated, and instead "local.arpa." is managed as a single zone implemented by a loose collection of hosts cooperatively executing a distributed algorithm. From that philosophical difference, a variety of implementation differences emerge. I'm sure there will be a lot of questions and disagreements, which I will try to answer both on the list and at the meeting in London. >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Performing DNS queries via IP Multicast > Author(s) : S. Cheshire > Filename : draft-cheshire-dnsext-multicastdns-00.txt > Pages : 19 > Date : 17-Jul-01 > >Multicast DNS is a really obvious idea, whose time has finally come. >This draft proposes one possible way of making it work. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-multicastdns-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Discovering Named Instances of Abstract Services using > DNS > Author(s) : S. Cheshire > Filename : draft-cheshire-dnsext-nias-00.txt > Pages : 10 > Date : 17-Jul-01 > >This document proposes a convention for naming and structuring DNS >resource records that allows clients to discover a list of named >instances of a particular given desired type of service. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-cheshire-dnsext-nias-00.txt Stuart Cheshire <cheshire@apple.com> * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.
- Multicast DNS and Multicast DNS Service Discovery Stuart Cheshire