Re: [mdnsext] mDNSext features/requirements rollup

[Alf Watt <[e-mail]>]

I think Andrew's point is worth taking the time to seriously consider. We already have dynamic DNS update but as previously mentioned configuration of the DNS server and it's clients out has proven to be either too difficult or not of interest to various OS vendors.

It's worth mentioning that Apple has all the parts in place to pull this off:

- A Server OS with an embedded DNS server which they provide a UI to manage
- Traditional and Mobile Clients with mDNSResolvers running on them
- A profile distribution system which make pushing configuration options including keys easy

Given the will to get the features implemented Apple could solve part of the problem this without any changes to mdns.

There are still things that fall outside of that scope which we should consider, but ignoring the opportunity to uses the existing protocols seems like a lot of effort to reproduce work that already exists.

Best,
Alf

On Jan 28, 2013, at 12:03 PM, [e-mail]<mailto:[e-mail]> wrote:

From: Andrew Sullivan <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mdnsext] mDNSext features/requirements rollup
Date: January 28, 2013 9:34:00 AM PST
To: <[e-mail]<mailto:[e-mail]>>


On Mon, Jan 28, 2013 at 11:51:02AM -0500, RJ Atkinson wrote:

Some of us would like to see mDNS support multiple IP subnets
(e.g. multiple buildings, multiple groups, multiple (V)LANs)
within a single administrative domain (e.g. university campus,
corporate campus).

 This implies having a straight-forward way to configure
 networking devices (e.g. firewalls, routers) at the edge
 of one's administrative domain to exclude certain interfaces
 (e.g. exterior uplink interfaces) from all mDNS traffic
 of the administrative domain using mDNS.

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?

A

--
Andrew Sullivan
[e-mail]<mailto:[e-mail]>