Re: [mdnsext] mDNSext features/requirements rollup

[Andrew Sullivan <[e-mail]>]

On Mon, Jan 28, 2013 at 02:52:51PM -0500, Brian Dickson wrote:
> The risks I see (in exclusively working on tools) are:

> - scope creep
> - scaling problems (in terms of development resources)
> - work done by those who do not fully understand DNS protocols
> - work done by those who do not fully understand DNS namespaces

> - work supported by vendors who have history of horrible implementations
> - tools in one space breaking things in another space (creating a Hobsons'
> choice for users)
> - users
> - firmware
> - longevity of deployed hardware/firmware/software

I have removed from your list all the issues that are _not_ also true
of extending mDNS, and will add to that the risks of extremely
surprising behaviour to users when mDNS doesn't work consistently from
one site to another.  That risk leads us to the problem that, in
future when people have name resolution problems in large networks,
we'll get to chase _two_ protocols in every case. 

Or put this another way.  We today have two DNS-like name spaces: the
mDNS one, which is link local, and the global DNS one.  At the moment,
your problem of debugging collisions between these two is restricted
to link local scope.  This makes the problem not completely
intractable.  

As the history of NAT (and DNS split horizon) appears to suggest,
there may be no practical way to be absolutely sure these extended
mDNS queries won't leak past the organizational boundary.  If that's
true, then what extending mDNS really represents is "create two
completely different but apparently related global name spaces and oh,
by the way, one of them doesn't work all the time."  

> > people are asking for a single, unifed namespace outside the
> > link-local context, and we invented a mechanism for that many years
> > ago.

> Just to be clear, which mechanism is that to which you refer?

DNS.

A

-- 
Andrew Sullivan
[e-mail]