DNS-SD, mDNS and dyn-DNS [was Re: Gnome VFS - plans for Gnome 2.8]

[Mark McLoughlin <mark skynet ie>]

Hey,

On Fri, 2004-03-26 at 23:18, Sean Middleditch wrote:
> On Mar 26, 2004, at 5:55 PM, Ian McKellar wrote:
> 
> > On Fri, 2004-03-26 at 09:38, Sean Middleditch wrote:
> >> The problem there is that Rendezvous is currently mDNS only.  This is
> >> only a limitation of Rendezvous, which is just one implementation of
> >> Zeroconf.  DNS-SD does not need to be limited to mDNS.
> >
> > That is true. I wonder if that new dynamic DNS thing thats in recent
> > versions of BIND would play nicely with DNS-SD...
> 
> Yes, it will.  That is why DNS-SD is so wonderful - it just works with 
> all the existing infrastructure we have and administrators are already 
> used to managing.  :)
> 
> I believe the tmdns implementations support dyn-dns already.  Several 
> others do as well.

	I had a good look at this a while back when I was considering using it
for Vino (I still am), and it seems I came to the conclusion that
dyn-DNS isn't very useful here because most admins wouldn't want to
enable it. Not sure how true that is ...

	Anyway, the writeup I did at the time is appended for people who don't
know what we're talking about and don't want to have to read the RFCs
:-)

Cheers,
Mark.

7.6. Service Discovery
======================

	In order to implement the ability to browse the network for
available remote desktop servers there must be some way to enumerate
the available servers. One possible mechanism for doing this is DNS
Based Service Discovery[17], a draft of which is currently on the IETF
standards track.

	DNS-SD is a convention for naming and structuring DNS resource
records such that a client can query the DNS for a list of named
instances of a particular service. The client can then resolve one of
these named instances to an address and port number via a SRV[18]
record.

	In the remote desktop case, a client could query the DNS for
PTR records of _rfb._tcp.<domain> and would be returned a list of
named instances of RFB servers, using TCP, on the domain. For example:

PTR:_rfb._tcp.ireland.sun.com -> SRV:Mark's Desktop._rfb._tcp.ireland.sun.com
                                 SRV:Gman's Desktop._rfb._tcp.ireland.sun.com

	(Note the way the Service Instance Name is a user-friendly
name containing arbitrary UTF-8 encoded text. It is not a host name.)

	The client would then display the list of available remote
desktop servers - i.e. "Mark's Desktop" and "Gman's Desktop" - and
allow the user to choose one. If the user chooses "Mark's Desktop" the
client can then resolve that SRV record associated with the remote
desktop instance.

SRV:Mark's Desktop._rfb._tcp.ireland.sun.com -> markmc-box.ireland.sun.com:5900

	The client can then resolve the "markmc-box.ireland.sun.com"
hostname and using the resulting ip address connect to the remote
desktop server on port 5900.


	While DNS-SD seems like a perfect mechanism by which remote
desktop instances may be queried for, there remains the problem of how
the DNS is populated with the details of these services to begin with.

	A related draft proposal on the IETF standards track is
Multicast DNS[19]. The idea behind Multicast DNS is to allow a group
of hosts on a local link, in the absence of a convetionally managed
DNS server, to co-operatively manage a collection of DNS records and
allow clients on that same local link query those records.

	The scheme works by each client connecting to the mDNS
multicast IPv4 address and sending/receiving DNS-like queries/answers
to port 5353. Between them, the clients manage the top-level ".local."
domain and negotiate any conflicts that arise. So, for example, the
host referenced by "markmc-box.ireland.sun.com" in the above example
could also be resolved using the host name "markmc-box.local" by other
Multicast DNS clients on the same link.

	In order to be queriable by Multicast DNS, our remote desktop
server could act as a Multicast DNS Responder and Querier and register
the remote desktop service there. Here's how the example above would
look like if we were using mDNS:

	Client queries the local link for remote desktop servers ...

PTR:_rfb._tcp.local

	... and receives a reply first from markmc-box ...

                    -> SRV:Mark's Desktop._rfb._tcp.local

	... and then a reply from gman-box:
	
                    -> SRV:Gman's Desktop._rfb._tcp.local

	Once the user has selected "Mark's Desktop" from the displayed
list, the client resolves that service and receives a reply once again
from markmc-box:

SRV:Mark's Desktop._rfb._tcp.ireland.sun.com -> markmc-box.local:5900

	The client then resolves "markmc-box.local" to an ip address
(still using Multicast DNS) and connects to that address on port 5900.

	Luckily, implementing this won't require writing an mDNS
implementation from scratch. There is an existing implementation in
GNOME CVS which integrates nicely with glib's main loop and there are
plans to centralise this in a desktop service advertisement and
discovery daemon.


	Another possible mechanism for making remote desktop service
information available via DNS is to use Dynamic DNS Updates[20] to add
DNS-SD records to a conventional DNS server. However, the majority of
DNS server deployments restrict (for obvious security reasons) the
ability to update DNS records completely or to only a few known
hosts. Because using this mechanism would require installation sites
to change their DNS administration policies, this is obviously not an
attractive option.


[17] - DNS-Based Service Discovery:
	http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt

[18] - A DNS RR for specifying the location of services (DNS SRV):
	http://www.ietf.org/rfc/rfc2782.txt

[19] - Performing DNS Queries via IP Multicast:
	http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt

[20] - Dynamic Updates in the Domain Name System (DNS UPDATE):
	http://www.ietf.org/rfc/rfc2136.txt