[dnssd] Site deployment options

RJ Atkinson <rja.lists@gmail.com> Thu, 24 July 2014 10:37 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AE31A01AE for <dnssd@ietfa.amsl.com>; Thu, 24 Jul 2014 03:37:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfWhlYnNUIvj for <dnssd@ietfa.amsl.com>; Thu, 24 Jul 2014 03:37:23 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A91B1A01A9 for <dnssd@ietf.org>; Thu, 24 Jul 2014 03:37:23 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id bs8so3696838wib.2 for <dnssd@ietf.org>; Thu, 24 Jul 2014 03:37:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Gn0tPNydSqU6aUB5ppF0rryhpi2OrjaTgayB6E5C2r4=; b=XnzSuGYAhHVdF5N43tZZx7sQa9DL6hFwpD+fXENM5lXquMAmqst1yZv6xKQo9bDjJq E4suQrqVoUk9Hoi7Y7wUO+/AHJRNPAG+UvHXQJ+dDSqaX4367A4GWjqtMalmVJniiCW4 1ZLfsZIpvncVjmfkFXjFK9rLCSfVowqzwb6gLEzFJCgYhVYjRDB5Yqrs+AnqCMqmp4DF dNyCz4F8pE4AEjzyji8Z0Pj5JvUHqpVh/+Wxdzsu/MpJapYXuzyPszg0WambT75YskgB Tiv5o6eOHcgoNnC+rH5SCmgnaCfOhmU/6nH2+/NvpK19CSxN0CSXn7oaLLITvw4W2C/P ysjw==
X-Received: by 10.194.222.230 with SMTP id qp6mr10853772wjc.23.1406198240360; Thu, 24 Jul 2014 03:37:20 -0700 (PDT)
Received: from dhcp-92f8.meeting.ietf.org (dhcp-92f8.meeting.ietf.org. [31.133.146.248]) by mx.google.com with ESMTPSA id o12sm21433995wiw.5.2014.07.24.03.37.19 for <dnssd@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 03:37:19 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1283)
From: RJ Atkinson <rja.lists@gmail.com>
In-Reply-To: <15473CC1-E1C2-4AF1-AD2B-542AA138B0F2@bangj.com>
Date: Thu, 24 Jul 2014 06:37:17 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <63C12F9B-63BD-4DC6-83C5-A6608FDA7568@gmail.com>
References: <0644A943-80B9-42E0-BF82-3E1113710FA2@gmail.com> <20E4ED19-12BD-45D4-B690-8629B552B23B@gmail.com> <15473CC1-E1C2-4AF1-AD2B-542AA138B0F2@bangj.com>
To: dnssd@ietf.org
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/dLBqkEoLJzCVeEZjnMwIfJSn3MI
Subject: [dnssd] Site deployment options
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Thu, 24 Jul 2014 10:37:25 -0000

On 23  Jul 2014, at 21:43 , Tom Pusateri wrote:
> mDNS advertisements are link-local.

Agreed.

> Whether mDNS uses GUAs, ULAs, or link-local addresses is irrelevant.
> 
> I'll assume you meant the broader term DNS-SD. If so, then the scope
> of the address is a matter best left up to the particular use case.
> There are arguments for all of them and a mix of them depending on
> what you're trying to achieve.

Yes.  There are a range of use cases.  These use cases will vary
in multiple dimensions, not just in choice of IP addressing model.

For example, separate from the question of which types of IP addresses 
a particular operational domain uses internally, there will be 
variation in whether/how the ordinary (unicast) DNS is deployed.

Considering the DNS axis of variation, one can imagine reasonable 
deployments where the operational domain might fall into one of 
several very different use cases:
	A) has no deployment of (unicast) DNS
	B) has a single (unicast) DNS instance of example.com,
           where the internal view is identical to the external view
	C) has a split-horizon DNS deployment of example.com
	D) other reasonable use cases probably exist

Case (A) probably describes a large number of home networks
and a fair number of small enterprise networks (e.g. dentist's 
office).

Further, for case (B), a small site with its own domain name
(e.g. example.com) might not have any full-time IT staff and
might not have direct configuration control over the contents 
of its DNS.  It might, for example, have outsourced its DNS 
to a service-provider, which in turn provides a web portal and 
a (very) limited set of configuration options (e.g. ability 
to specify IP addresses for a very small number of pre-defined 
network services such as inbound mail-relay and public web server).

Case (C) probably is done most often at larger sites where 
full-time IT staff exist and the organisation's DNS instances
are directly managed by their IT staff.

Note well that any of these DNS deployment cases (A-D above)
might use any combination of private-scope IPv4 addresses, 
IPv6 ULAs, and global-scope IP addresses for their unicast 
IP addressing deployments.  As near as I can tell, addressing
options are orthogonal to the DNS deployment options.

> Bots operate inside private networks and can do as much damage
> with ULAs as with GUAs.

Yes.  This means that defense-in-depth usually is the best option,
where one has a firewall and also has other measures.  However,
general operational security concerns properly are topics for 
the IETF's OPsec WG.

Bottom-Line:
------------
DNS-SD needs to work well regardless of the unicast IP addressing
used and regardless of the (unicast) DNS deployment model used.

I believe this is entirely possible -- without changing the large
installed base of systems that support (mDNS + DNS-SD) today.

Yours,

Ran