Re: [dnssd] Example Use Cases (was Re: Rechartering)

Tom Pusateri <> Fri, 20 July 2018 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7290E130E16 for <>; Fri, 20 Jul 2018 11:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ym6JCRiYTNQt for <>; Fri, 20 Jul 2018 11:03:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BEBE7130DE7 for <>; Fri, 20 Jul 2018 11:03:58 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3667B9A; Fri, 20 Jul 2018 14:02:00 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Tom Pusateri <>
X-Mailer: iPhone Mail (16A5327f)
In-Reply-To: <>
Date: Fri, 20 Jul 2018 14:03:57 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "R. Atkinson" <>
Archived-At: <>
Subject: Re: [dnssd] Example Use Cases (was Re: Rechartering)
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Jul 2018 18:04:03 -0000

Thanks Ran. 

I think this is important input for the reCharter. 


> On Jul 20, 2018, at 12:44 PM, R. Atkinson <> wrote:
> I’d like to talk a little bit about use cases relating to both mDNS & DNS-SD.
> This is mostly prompted by the rechartering slides (which I read online,
> although I have not been in Montreal for IETF this week).
> These are partly baked thoughts, written in haste, so are incomplete
> and probably have typing/editing errors in places.
> 1. ZeroConf / No Infrastructure Case
>   In my experience as a user and as a consultant, is that most (non-IETF :-)
>   residences and most small-businesses fundamentally want a zero 
>   configuration network.  The outer limit of what they might view as 
>   acceptable infrastructure is enabling a DHCP server (facing to the interior) 
>   on a (small) site border router that uplinks to some ISP. 
>   These sites have viewed the “magic” appearance of “it just works” 
>   mDNS + DNS-SD as a huge win — a win that they really do not want
>   to lose.  The main application benefit I see is printer discovery, but 
>   there are other services that do get advertised and also get used
>   via the existing widely deployed mDNS + DNS-SD combination.
>   (Again, their preference is for a Zero Configuration network, even if
>    that means a less secure interior network deployment.)
>   In this environments, the site border router typically just learns its IP address
>   and other configuration (e.g. ISP’s DNS resolvers) by running a DHCP/DHCPv6
>   client on the exterior router interface and trusting the ISP’s DHCP reply.
>   The same router runs a DHCP/DHCPv6 server on the interior interface,
>   and the router’s DHCP replies carry along DNS resolver information learned
>   from the DHCP client on its exterior interface.  The site does not itself
>   have a DNS server or even its own DNS resolver.
>   In these environments, I rarely see any servers within a small business.
>   They might have a web site and email, but those often are outsourced
>   to someone other than their ISP.  Email very often is really web-based email.
>   If they happen to have their own domain name (, they
>   usually are NOT running the DNS name server for that and they are NOT
>   using that domain name on internal machines.  Instead, their domain name
>   is advertised by their (outsourced) web site hosting company, which often
>   also is providing them with web-based email.
>   Medical offices (in my neighborhood) seem to be migrating to “electronic
>   records”.  In practice, this often means some deal with a local hospital.
>   The servers are run at the hospital IT department and client-server type
>   software is installed on the medical office computers (or a web application
>   is used instead), but the servers are all offsite and run by someone else.
>   Privacy laws/regulations on medical data are growing, even outside the EU,
>   and a common belief is that it is better to outsource the implementation
>   so that some other organization is responsible for privacy & security
>   compliance (e.g. HIPAA).
>   These sites LOVE the existing mDNS + DNS-SD solution.  Their only real
>    wish is that if they have 2 or 3 subnets, they could somehow have a single
>    operational mDNS environment (instead of having one mDNS environment
>    per subnet).  At least some of my clients have enabled a non-standard mDNS
>    proxy that is available from a well-known IP router vendor.  At their scale,
>    they are happy with that router vendor’s approach.  I worry a bit that in a
>    larger network environment too much bandwidth would be consumed 
>    (as happened historically with SLP) by that vendor’s implementation approach.
>    As I have mentioned to Stuart at least once in the past, these folks really
>    want something that looks/feels/behaves like the old AppleTalk/EtherTalk
>    system — although most clients don’t use that terminology (because they
>    were not working age when those capabilities were widely deployed by sites
>    with Apple products).
> 2.  Larger Enterprise / Campus / Building-sized Case
>    Larger businesses usually do have their own internal mail servers, file
>    servers, and DNS servers.  Often their authoritative DNS servers are
>    different/separate from their DNS resolvers.  These often have 2 logically
>    different WiFi networks, one for employees/internal-users and one for
>    guests.  Sometimes the “guest” wireless is outside a corporate firewall
>    and only sees the public Internet.   Other times the “guest” network is in
>    a kind of DMZ environment, so that guest’s can discover printers and
>    send out print jobs, but does NOT have unconstrained access to the
>    organization’s internal network.
>    In this environment, often there is more concern about “security”, which 
>    seems to mean some combination of “access control” (about what a 
>    given node can see) and “authentication” (for DNS updates) relative to 
>    DNS service advertisements.  (In the extreme, I have a client who turns
>    on every possible security feature, including use of things like 802.1x.
>    This results in a more secure, if somewhat more brittle, deployment.)
>    In this environment and for these users, there is MUCH more willingness
>    to have IT staff configure “infrastructure” (e.g., routers, switches, servers, proxies)
>    than in Case 1 at top of this email.  This customer type also is MUCH more
>    interested in using access controls and/or cryptographic authentication for
>    any service advertisements and for any kind of DNS update.  
>    However, in my experience, these customers do NOT want to configure 
>    the end-user devices — at least not beyond whatever DHCP (or DHCPv6
>    + IPv6 ND) can provide by way of automatic configuration.
>     Note that users in this category often want to see services for their
>     (logical) organization, regardless of where they are within the campus
>     (or which campus for multi-campus organizations).  Someone who works
>     in “engineering” wants to see all of the “engineering” groups services
>     plus whatever printers are geographically near the person’s current
>     location.  In old AppleTalk this flexibility was pretty easily deployed and 
>     also pretty easily used.
> Postulate:
>    My postulate, again based on my own non-scientific sample, is that there
>    are at least 2 distinct use cases for DNS-SD (and mDNS).  One case is
>    small scale, so scalability of solution is not as important.  The other case
>    requires scalability.  The small sites are not usually very security conscious,
>    while the larger sites usually are very security conscious.
>    So it is conceivable that some potential products of this WG might apply
>    to one use case, but not to the other use case.  I think we need to all keep
>    both use cases in mind as the WG ponders current/future work in this WG.
> Yours,
> Ran
> _______________________________________________
> dnssd mailing list