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.