Subject: [mdnsext] mDNSext features/requirements rollup

From: RJ Atkinson <[email-masked]>
Date: Mon, 28 Jan 2013 11:51:02 -0500

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.

To a first approximation, the facility/capability provided 
by (old) Apple EtherTalk would do very nicely. 

Kindly note that the ability to group a resource into a 
non-topological "zone" within that single administrative domain 
would be most helpful.

Overall bandwidth efficiency is also important as a design
goal.  Some of us have a mixture of different links/subnets
with different technologies and bandwidth limitations --
not everything is running at Gbps speeds, over fibre, or
over uncontested radio spectrum.[1]

Ran

[1] Exempli Gratia:   IEEE 802.11n does NOT operate at full 
    theoretical performance in typical 2.4 GHz deployments,
    because of the widespread use of the 2.4 GHz band for
    a wide range of things -- other 802.11 deployments,
    cordless telephones, and so on.  While the 5 GHz band
    often has less interference at present, that also is
    shared, so interference there will tend to grow over
    time.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Jan 2013 12:34:00 -0500

>   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
[email-masked]

---

From: nudge <[email-masked]>
Date: Mon, 28 Jan 2013 18:38:36 +0100

> why wouldn't it be better to take that energy and expend it on the

Because there's more money to be made being dns experts in a poorly
equipped world ?

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Jan 2013 12:54:29 -0500

> Because there's more money to be made being dns experts in a poorly

And larding up mDNS does not re-instantiate this problem how, exactly?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian Dickson <[email-masked]>
Date: Mon, 28 Jan 2013 14:52:51 -0500

On Mon, Jan 28, 2013 at 12:34 PM, Andrew Sullivan <[email-masked]>wrote:

> by vastly improved tools for real DNS management.

I think one of the fundamental problems is, that by merely existing,
mDNS has created two namespaces, where the link-local (yes/no)
is the only identifying attribute for which namespace applies.

Also, creating/improving tools, in general, has certain risks, unless
improving things from implict -> explicit (mDNS vs DNS namespace) is done
first.

The risks I see (in exclusively working on tools) are:
- open/standardized tools vs proprietary
- 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 done by idiots
- 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

>  It seems to me that

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

Brian

>
> --
> Andrew Sullivan
> [email-masked]
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Jan 2013 15:36:04 -0500

> - 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."  

> > ago.

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

DNS.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tim Chown <[email-masked]>
Date: Mon, 28 Jan 2013 22:32:29 +0000

> to link local scope.  This makes the problem not completely

We are putting a BoF request to the AD(s) for Orlando. The request is phrasing the BoF as "Wide area DNS-SD", though for practical reasons we'll likely keep the same mdnsext acronym if the request is approved.

The goals have been revised from the previous BoF, with the proposed zeroconf and unicast DNS goal revised to be a BCP on their coexistence, which could describe some of the issues discussed here and elsewhere recently.

Whether the Bof goes ahead will depend on the AD(s) view(s) as well as evidence of commitment and work here. Further good progress on the requirements
draft would be welcomed.

Tim

---

From: David Farmer <[email-masked]>
Date: Mon, 28 Jan 2013 19:07:22 -0600

> why wouldn't it be better to take that energy and expend it on the

If you mean an implementation of Wide-Area DNS Services Discovery then 
yes, but most of the zero-conf implementations and the applications 
using this have ignored anything but mDNS and Link-Local DNS Services 
Discovery.

The real issue is that end-users and even IT Executives (CIOs, etc...) 
don't see why there should be any difference between what they can do 
and use at home and in the office.  If they can do wiz-bang-thing at 
home they want to do it in the office.  Right now mDNS and Link-Local 
DNS Services Discovery are critical to how many of these consumer 
devices, or the Internet-of-things that some people call it, make the 
wiz-bang-things work.

I apologize to Apple, but to really make this clear I have to call them 
out.  The driver behind the petition is a specific case of what I 
generically described above.  Users and IT Executives in Higher Ed 
wanted to be able to use AirPlay Screen Mirroring to Apple TVs from iOS 
and now Mountain Lion Laptops on the campus network.  Not only was this 
an idea they came up with but, Apple even had an TV ad campaign 
promoting the idea.  To be honest as a network engineer its very much an 
uphill battle when your arguing against a multi-million dollar TV ad 
campaign. :(

So you hear a bunch of us pushing to solve this with network hacks, or 
mDNS hacks.  Not because we think it is really the right way, but 
because the network is what we can effect, its the levers we can 
control.  The applications and wiz-bang-thing devices are out of our 
control and, right or wrong, we have had exceptions placed on us to make 
them work on our networks.

So, while it may not be the right thing, I need a way to make normal 
mDNS and Link-Local DNS Services Discovery work on my network.  Which 
consists of multiple segments and the services the users want may or may 
not exist on the same segment.  Fundamentally, this is either a symptom 
of the success of mDNS and Link-Local DNS Services Discovery or a 
failure to think through the consequences of not including broader 
scalability in the original solution, take your pick.

So while we need the better DNS tool you refer to, we also need 
solutions that work with the applications and wiz-bang-thing devices 
that are out there now.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 29 Jan 2013 09:23:57 -0800 (PST)

Hello,

> scalability in the original solution, take your pick.

  What you're asking for is for networking devices like routers and firewalls
and the like to provide a form of proxying for these link-local DNS services
discovery. This can be enhanced by using smarts in the network (e.g. is the
authenticated wiz-bang-thing authorized to make such a query?) and by
explicit config of the networking device. The nice thing about this is that
none of the wiz-bang-things need to be touched, they do what they always
did but get a much more rich response.

  This seems to me like a well-defined problem we could work on that could
produce a useful RFC.

  regards,

  Dan.

---

From: "Stephen Orr (sorr)" <[email-masked]>
Date: Tue, 29 Jan 2013 18:11:59 +0000

I agree with Dan on this - making sure that the network infrastructure has the ability to operate as good "mdns clients" while providing filtering/proxying of DNS-SD advertisements between L3 segments would be a fundamental use case.

How the information gets displayed, searching etc would be left up to the client GUI.

Stephen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Harkins
Sent: Tuesday, January 29, 2013 12:24 PM
To: David Farmer
Cc: [email-masked]; Andrew Sullivan
Subject: Re: [mdnsext] mDNSext features/requirements rollup

  Hello,

On Mon, January 28, 2013 5:07 pm, David Farmer wrote:
> control and, right or wrong, we have had exceptions placed on us to 
> make them work on our networks.
>
> consists of multiple segments and the services the users want may or 
> may not exist on the same segment.  Fundamentally, this is either a 
> symptom of the success of mDNS and Link-Local DNS Services Discovery 
> or a failure to think through the consequences of not including 
> broader scalability in the original solution, take your pick.

  What you're asking for is for networking devices like routers and firewalls and the like to provide a form of proxying for these link-local DNS services discovery. This can be enhanced by using smarts in the network (e.g. is the authenticated wiz-bang-thing authorized to make such a query?) and by explicit config of the networking device. The nice thing about this is that none of the wiz-bang-things need to be touched, they do what they always did but get a much more rich response.

  This seems to me like a well-defined problem we could work on that could produce a useful RFC.

  regards,

  Dan.

---

From: David Farmer <[email-masked]>
Date: Tue, 29 Jan 2013 12:59:51 -0600

As a first step I'm ok with this, in fact I'm already doing it, but I view this as mostly a work around or hack.

1. What happens if you get a proxy loop?  This seems really bad! Right now I have nothing to prevent this.

2. Maybe loop detection can be defined as part o a proxies behavior.

3. Creates the same problem AppleTalk had, routers involved in the name binding protocol. This is especially a problem for most enterprise network gear with powerful fast-path ASIC switching and relatively low powered slow-path processors.

4. Doesn't really solve any multicast traffic issues or scaling of the name space. Yes, it's not the network's problem to display 100s of services, but it will be a problem with most of the GUI's I've seen.

5. What about IPv6, mDNS is using link-local IPv6, how do you route between multiple IPv6 link-local, by definition you can't. So multi network mDNS is really IPv4 only right now.

So a proxy that safely interconnects multiple link-local nets is only one small part of the solution space we need.  That is only a start, but an important start.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota    
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================