[dnssd] DNS UPDATE access control in DNS-SD

Matthias-Christian Ott <ott@mirix.org> Sun, 27 March 2016 20:29 UTC

Return-Path: <ott@mirix.org>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF07212D140 for <dnssd@ietfa.amsl.com>; Sun, 27 Mar 2016 13:29:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 eMF9cJ7skWaj for <dnssd@ietfa.amsl.com>; Sun, 27 Mar 2016 13:29:25 -0700 (PDT)
Received: from mirix.in-vpn.de (mirix.in-vpn.de [IPv6:2001:67c:1407:a0::1]) (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 4BA4412D0F7 for <dnssd@ietf.org>; Sun, 27 Mar 2016 13:29:23 -0700 (PDT)
Received: from [::1] (helo=localhost.localdomain) by mirix.in-vpn.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) id 1akHIV-0007Vk-Sf for dnssd@ietf.org; Sun, 27 Mar 2016 20:28:32 +0000
To: dnssd@ietf.org
From: Matthias-Christian Ott <ott@mirix.org>
Message-ID: <56F8429D.3070402@mirix.org>
Date: Sun, 27 Mar 2016 22:29:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnssd/URl2BbaG4s7n_3pAkVyEBCzpKbs>
Subject: [dnssd] DNS UPDATE access control in DNS-SD
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.17
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: <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: Sun, 27 Mar 2016 20:29:26 -0000

Using DNS UPDATE for updating DNS-SD and SRV RRs in general requires
multiple hosts to be able to update a shared domain name. If you want to
limit the damage of a single host to itself, a DNS server that handles
updates for the domain name would have to examine the RDATA section in
order to decide whether to allow an update or not.

Assume for example that there a two hosts a.example.com. and
b.example.com. Both hosts provide IMAP services and therefore would need
to be able to update RRs _imap._tcp.example.com. (either PTR RRs or SRV
RRs depening on whether you use DNS-SD or plain SRV RRs). If you grant
both hosts access to update _imap._tcp.example.com. and the update
credentials (TSIG or SIG(0) key) of one of the hosts is compromised, it
would be possible to remove the other host from _imap._tcp.example.com.
and therefore to deny service for that host.

Besides that I'm not aware of any DNS server that would support
examining the DNS RDATA section (not even even the "external" access
control mechanism of BIND does).

Was that a scenario that was considered in the architecture of DNS-SD?
Is there a way to handle this scenario without examining the RDATA section?

- Matthias-Christian