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

"R. Atkinson" <rja.lists@gmail.com> Fri, 20 July 2018 16:44 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 49D88130F3E for <dnssd@ietfa.amsl.com>; Fri, 20 Jul 2018 09:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OWgAcnZhB_RQ for <dnssd@ietfa.amsl.com>; Fri, 20 Jul 2018 09:44:50 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B361130E54 for <dnssd@ietf.org>; Fri, 20 Jul 2018 09:44:50 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id a5-v6so10822962qtp.2 for <dnssd@ietf.org>; Fri, 20 Jul 2018 09:44:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=R6KD+Azv8GO7yPGP0Zd6DJ0C9nXSbVtHvlNVWEh7DYI=; b=ECrIp7qci4qTw40rtqDCF9kU88g79qQ7Lo36IzMJGfWwaDWmsMelFNxEi3KNHIu811 BWn+DfyZ59sKr/ozlNnFlmNw5Ur6VDUCyxVWL695YP7B4hdN3dwCCyDO5eB9tVQIfEEc 62c2GZcpUCUxuFldQXpGiTgk/tjYO+BFY1aDyPlxFnakO1gm6g3FxEe1BYjV30nQCDng LlrbRqM1soJOyUiuPAtJRWSXiYpKdiVXhZdqkkoc/tGmFIs36aMlHrGVqNHFAZ/X9jBi 4yXkxQj/hsaF9p9ifUeDrTqgi267l0BOE3axKq0VD/wx44dFIEvsRO27hJAYR3rYv43u gLfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=R6KD+Azv8GO7yPGP0Zd6DJ0C9nXSbVtHvlNVWEh7DYI=; b=V18Tbk/lkNDYS2bFU8w5QPoZwDA8Gu78sNidU6KELEIfWdU+5OWWM1cVBhAosTeHYG gAIDJ0VycPGVIEnxX31O5mXXzlOhi/6+tBa8h2zEEq4+ZqGU5dtlogtqRKyftZAPpCvB x8az+UALdHS63TSilsZDulVVMdwI4fBr7pd3vqSGg54Zw6J1nXgUop2W6LazdCgMaQo1 ntpyiQbfzK3eKrd2PDOaqz+ZZFaqOdNYG5LL6mWrUOyVCxHM0YPwo/7xZrhJy7XOq1Qq J4FBby7G1DqGtKg5B56Iaq6zLDT8+w6qDAw72XBN7vTA9i+j8P7rMr+LRJFbyi6jBK0K TUNg==
X-Gm-Message-State: AOUpUlEzxLcpjh9cYvue/csQU8zUgNtFj4KrRFhO7ELqvv5ELGGxNR12 ElRZn3buyf8IFWoQeZb6/ajSPeYu
X-Google-Smtp-Source: AAOMgpdmMLv14IA/ZMhZty7OXj4gg+XaFOmr+nJrCAMsrrsSlgloYl3l/OhEzJTPChisHYnYFCn7aw==
X-Received: by 2002:ac8:242b:: with SMTP id c40-v6mr2634840qtc.209.1532105089244; Fri, 20 Jul 2018 09:44:49 -0700 (PDT)
Received: from [] (pool-96-241-84-161.washdc.fios.verizon.net. []) by smtp.gmail.com with ESMTPSA id 14-v6sm991142qty.57.2018. for <dnssd@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Jul 2018 09:44:48 -0700 (PDT)
From: "R. Atkinson" <rja.lists@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Message-Id: <E7BC51A1-8E17-44B1-BE3A-066068757521@gmail.com>
Date: Fri, 20 Jul 2018 12:44:47 -0400
To: dnssd@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/AOiEI7gcx6lbVBzXtIr6c8mPr5k>
Subject: [dnssd] Example Use Cases (was Re: Rechartering)
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jul 2018 16:44:53 -0000

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 (example.com), 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.


    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.