Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?

Paul Wouters <paul@nohats.ca> Sat, 01 December 2018 15:49 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9E31277D2; Sat, 1 Dec 2018 07:49:51 -0800 (PST)
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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 FVTZc4qCECR5; Sat, 1 Dec 2018 07:49:49 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3ED12426A; Sat, 1 Dec 2018 07:49:49 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 436bL171N5zMS1; Sat, 1 Dec 2018 16:49:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1543679385; bh=C6BgE8y/UnPjti0gj+aYOlUbsfwdfiVXKy8sQeJTTEM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Yv0X3s7IrClckyPm35BWPoQN9bZ5vLu0zbGQcOdiKYVu0fP8jhBbtLCYNUZOQ58ZP MEAfCM+ufmqPx5ePwtrsMFY8X1kCw3SY+Ba6MigOgP6TBfaZr30d258onA/a41Ru51 BUGxhBBpbBIYctiPf/fbnIJ0cmwE2oOn1LK1Wiyc=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Lae1ym1DL8Yn; Sat, 1 Dec 2018 16:49:45 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 1 Dec 2018 16:49:43 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id D2A48319421; Sat, 1 Dec 2018 10:49:42 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D2A48319421
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CCC4B40D37F8; Sat, 1 Dec 2018 10:49:42 -0500 (EST)
Date: Sat, 1 Dec 2018 10:49:42 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Scott Morizot <tmorizot@gmail.com>
cc: draft-ietf-ipsecme-split-dns.all@ietf.org, dnsop <dnsop@ietf.org>
In-Reply-To: <CAFy81rn9u+byrQokb9owbH6t6iPLar=zxs30TtZk1vtmtq9vmw@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1812011035170.5400@bofh.nohats.ca>
References: <CAHw9_iL6CpLf6h_ysWEjvNjzaU2TPk-SyVGzLs_J9Yk_5A4OmA@mail.gmail.com> <46B41554-ABC0-4939-99E3-703E1FD998D5@hopcount.ca> <alpine.DEB.2.20.1811261658250.3596@grey.csi.cam.ac.uk> <23550.37961.117514.513410@fireball.acr.fi> <CAHw9_iJ0XFzErwbUci_WmN1pzZHbapj2JNu4j2YbMFbBt-m+aw@mail.gmail.com> <CAPt1N1m2upV2yJsFVyac6n-_MzFsv_g_fMaYP_UueTFR_3OPCA@mail.gmail.com> <1FBDB971-A632-4E32-A6CF-D422BBF6F8D3@nohats.ca> <CAPt1N1nK=QurJGdoKhJfg6BV6yUn9dtWZBZDfE+PGDmm2SAdvw@mail.gmail.com> <alpine.LRH.2.21.1811301042420.22612@bofh.nohats.ca> <CAPt1N1=4hEMPgS3nJxPwjhhwY=nNDZrq7+dH0M313YBGbfkn3A@mail.gmail.com> <alpine.LRH.2.21.1811301216010.535@bofh.nohats.ca> <CAFy81rn9u+byrQokb9owbH6t6iPLar=zxs30TtZk1vtmtq9vmw@mail.gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/iWZfpuWBDvsbaQ6e4adRYxJ5F_w>
Subject: Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Dec 2018 15:49:52 -0000

On Sat, 1 Dec 2018, Scott Morizot wrote:

> I guess I'll speak up as someone who has been managing the DNS/DNSSEC design and implementation of a large
> organization with a complex set of DNS requirements

Thanks for the write up! It is always good to hear actual enterprise
deployments.

> We employed manual trust anchors at different phases of our implementation, but now have
> very few in place. One is to establish trust for an internal zone for which we do not control the administration of
> the parent zone.

So the interesting question here is, how is this one zone securely
resolved when you are connected to the network via a VPN? Or is this
zone not available for VPN users? And if this draft could make it
available, would you? Or, do your VPN users not use split-tunnel,
and connect to an inside DNS server once connected?

>       This scheme seems to require both inside and outside zones are signed
>       with the same key, or as Mark pointed out, both internal and external
>       zones need to share their DS records and keep these in sync. As these
>       are usually different organisations/groups/vendors/services, that is
>       an actual management problem.
> 
> 
> Or you can do what we did and place DS records for both the internal and external KSKs (using public placeholder
> versions of the internal child zones just to establish the delegation point) in the parent zone. That establishes
> chain of trust whichever version of the zone is resolved. That works whether the public version is just a
> placeholder with nothing else of significance in it or if it is a zone where both the external and internal records
> matter and are used by the appropriate source for the query, but differ.

That is a good solution as well. Although I would be a little worried that
a compromise of the public view could trick people into establishing the
"internal" zones in the external view to trick people into logging on
and giving out their password. But that is surely far down the list of
easy attacks to run.

> I don't really have any thoughts on the draft itself

That is too bad, because I'd be very curious how you handle DNSSEC with
your VPN clients. Not many large organizations run DNSSEC on both
internal and external views. So I am curious how you handle DNSSEC
for your (split?) VPN clients. But I understand if you cannot share
more data about that in a public forum.

> , but wanted to add my own real world experience with managing
> DNSSEC trust. On the validation side, we also don't allow any device in the enterprise network, including internal
> nameservers, to send or receive DNS queries to the Internet. Period. Only our perimeter recursive, DNS caches can do
> that and those will only accept queries from authorized enterprise recursive, caching nameservers. And we have
> protections, including different DNS blacklists, at each layer. So we have a lot of control over what devices
> connected to our network can and cannot do and they do not have unrestricted ability to query Internet DNS even
> through our multiple layers. We also use the cli version of dnsviz a lot to ensure we understand what different
> points on the recursive side of our enterprise DNS infrastructure are seeing.

So I guess the interesting thing here is the device that is in
split-tunnel mode. It would not receive the protection of your
DNS infrastructure for external lookups, so if you allow BYOD
to connect to your network, it would be bypassing those DNS
security checks for non-organisation DNS queries, which would
put the BYOD under greater risk. Perhaps you do not allow
split-tunnel or BYOD for those reasons :)

Thanks for your input,

Paul