Subject: Re: [mdnsext] mDNSext features/requirements rollup

From: James Andrewartha <[email-masked]>
Date: Wed, 6 Feb 2013 10:04:41 +0800

On Mon, 28 Jan 2013 12:34:00 -0500, Andrew Sullivan wrote:

> I still do not understand why this sort of thing isn't better handled
> by vastly improved tools for real DNS management.  It seems to me that
> people are asking for a single, unifed namespace outside the
> link-local context, and we invented a mechanism for that many years
> ago.  The problem is that the support tools for that mechanism sort of
> suck.  Instead of inventing a new protocol which, by definition, is
> going to run into conflicts with the existing protocols in this space,
> why wouldn't it be better to take that energy and expend it on the
> missing tools?

I too would like better real DNS management, however there are several
problems with it. Others have pointed out that existing implementations
are focused on mDNS and LL DNS-SD - is WA DNS-SD well tested, has a
useful client UI etc? Imagine having to reconfigure your DNS search
domains when you change location - sure this can be handled by DHCP, but
then you have to have lots of different scopes, which is another
management tool problem.

As for the server side of things, apparently some devices don't support
registration in DNS [1]. A suggestion was made to have a tool that
translates mDNS to updates to a WA DNS-SD domain, which could work, and
does allow administrator approval of what is visible, but there's still
the question of domain scope management. Never mind that some features
of Apple TVs just don't work over WA DNS-SD, only mDNS [2].

Even for applications/devices that do support registration, I don't know
if they support setting a scope for each record. As such, doing it once
at the network level is far easier than updating every DNS-SD publishing
application. For example, I recently discovered [3] that our printers
are published to Mac clients via mDNS from Papercut - how do I control
the visibility of printers in certain areas?

Going back to the broader topic, I also need different scopes for
different folk^Wservices - the area/networks a printer should be
advertised on are different to an Apple TV in a classroom. But a client
iPad needs to see both.

My use case is Apple TVs in each classroom, which I'd like to limit
geographically, both for ease of use (finding an entry is a list of 100
is not fun) and to prevent accidents (streaming to the wrong device).

[1]
http://listserv.educause.edu/cgi-bin/wa.exe?A2=ind1112&L=WIRELESS-LAN&T=0&F=&S=&P=52503
[2]
http://listserv.educause.edu/cgi-bin/wa.exe?A2=WIRELESS-LAN;0pol1g;20111220182540-0600
[3] After installing a new wireless network that appears to be having
trouble with multicast. I've since discovered printers can be pushed out
by profiles, but a) profiles suck compared to MCX, b) profiles have no
location awareness.

[late subscriber to the list, apologies for thread-breaking]

-- 
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Feb 2013 09:31:52 -0500

> then you have to have lots of different scopes, which is another

But you have this problem _by definition_ with mDNS.  It's always
localy scoped.  Indeed, that's what people are complaining about.

It seems to me that, in Internet terms, we really have three scopes:

    1.  my network;
    2.  my network_s_;
    3.  the Internet.

In naming, historically we've treated case (2) as a special case of
(3), and sometimes added split-horizon or something to it.  What
people are really asking for now is to treat case (2) as a special
case of (1), and figure out how to make that work.

The problem I see is that, because of historical practice, attempting
to treat (2) as a special case of (1) will mean that names designed to
be local to (1) will leak into (3).  The evidence for this is the
effectiveness of split-views at keeping "private" names off the
Internet.  This is only going to get worse as ICANN expands the root
zone (note there's an application for .mail, just for instance).
Similarly, RFC1918 addresses have often turned out to be globally
problematic because of their local scope.

I think that leaking locally-scoped names onto the public Internet is
going to be a bad thing, and that's why I'm arguing that what is
really needed is a way to bring an actual global namespace to this.
 
> registration in DNS [1].

Since we're attempting to make a new protocol, no matter what we do
some already deployed stuff isn't going to work with it perfectly.  If
what people want is a perfectly backward-compatible, do-what-I-mean
protocol that gives us all the new features we want for all the
existing stuff that works according to the previous protocol
specification, then I think we're going to be disappointed.

> is not fun) and to prevent accidents (streaming to the wrong device).

"And no administration."  We _had_ a solution for your use case as you
describe it: put things in the DNS, put a big label on the TV that has
the name of the device, and now you don't need to navigate drop-down
lists of 100s of devices.  But it means you need to manage the DNS,
and it probably means slightly different interface design both on the
iPad and the Apple TV.  I think I get why that's not desirable; I just
want us to be clear about what the challenge really is.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: James Andrewartha <[email-masked]>
Date: Thu, 7 Feb 2013 08:53:14 +0800

> really needed is a way to bring an actual global namespace to this.

Those are all very good points. Does the experience of Site Local
Addresses (RFC 3879) have any lessons here?

> specification, then I think we're going to be disappointed.

The primary reason this is being working on is Apple TVs. Read the
archives of EDUCAUSE that prompted the petition and forming of this
working group, it's all about streaming video from iPads to Apple TVs in
classrooms. And as has been established, Apple TV streaming doesn't work
with WA DNS-SD. If whatever new protocol extension or feature or
management tool we come up with isn't supported by Apple TVs, the whole
exercise has been pointless.

> want us to be clear about what the challenge really is.

I'm happy to put a label on things and tell teachers to put that in, but
apparently Apple is not. I'm happy to do some administration and
management, people have been doing it with printers for years. Anyway, I
don't really care what the solution is, so long as it works for Apple
TVs. It's Apple you need to convince about the suitability of using DNS,
not me.