[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
- [dnssd] Security through Obscurity RJ Atkinson
- Re: [dnssd] Security through Obscurity Tim Chown
- Re: [dnssd] Security through Obscurity Douglas Otis
- Re: [dnssd] Security through Obscurity Tom Pusateri
- [dnssd] Site deployment options RJ Atkinson
- Re: [dnssd] Security through Obscurity Tim Chown
- Re: [dnssd] Security through Obscurity RJ Atkinson
- Re: [dnssd] Security through Obscurity Kennedy, Smith (Wireless Architect)
- Re: [dnssd] Security through Obscurity Douglas Otis
- Re: [dnssd] Security through Obscurity RJ Atkinson
- Re: [dnssd] Security through Obscurity Michael Richardson
- Re: [dnssd] Security through Obscurity Michael Richardson
- Re: [dnssd] Security through Obscurity Albrecht, Harald
- Re: [dnssd] Security through Obscurity Michael Sweet
- Re: [dnssd] Security through Obscurity Kennedy, Smith (Wireless Architect)
- Re: [dnssd] Security through Obscurity Douglas Otis
- Re: [dnssd] Security through Obscurity Albrecht, Harald
- Re: [dnssd] Security through Obscurity Tim Chown
- Re: [dnssd] Security through Obscurity Albrecht, Harald
- Re: [dnssd] Security through Obscurity Michael Richardson
- Re: [dnssd] Security through Obscurity Michael Richardson