Re: [DNSOP] howto "internal"
Scott Morizot <tmorizot@gmail.com> Wed, 25 July 2018 20:32 UTC
Return-Path: <tmorizot@gmail.com>
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 7282A130E0A for <dnsop@ietfa.amsl.com>; Wed, 25 Jul 2018 13:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5Ja5w3A3pkH for <dnsop@ietfa.amsl.com>; Wed, 25 Jul 2018 13:32:12 -0700 (PDT)
Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 4EDC812E039 for <dnsop@ietf.org>; Wed, 25 Jul 2018 13:32:12 -0700 (PDT)
Received: by mail-ua0-x22b.google.com with SMTP id p22-v6so5954027uao.7 for <dnsop@ietf.org>; Wed, 25 Jul 2018 13:32:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=HshMKPbutGoI7FIUReblzbARVlibbcgEcw/euIxTduI=; b=ecJi+tK5cUNZSdjBvhOq81P18IXJls3pTA5dH99hT0QS0JBnLR/cpxvht/JNDvK6rS c9IOZVmB4to+igsr9//sw+UWqYqkbJ/bo1oGNZuruWVLrWqCbpxGLBCIwK0anP1KIESu 3nEs4NAul3kFGdtHmgo9g0r7WXfDqdlnxb1mgB/8+vpkUxYIh6isaQRzc7tcHwExOf1m y222tyePkjebamAvOTGhGhYwuQy1Q3W6NszJtgQb23fpiA1aVM9jVJeQANC/egc4CzTg j4uiqJT380tvMGdw6PotTvGPRoiQNxx9BYuXqVAUAuf7FD01wqPMLsMwQrhxwNY1jb55 lEoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=HshMKPbutGoI7FIUReblzbARVlibbcgEcw/euIxTduI=; b=YWb8Loy24d3AZVf8zBqOafYBmu20DB8h3g+oRGm/fJ3rkxzh/CkYHjboexb9KCUeMn DE6K9yFr+3dj2lIUwOphYTst6pDeCaCsAPmvFjHMpuhH23AJP3p9AvyXPRL0sU/Ylb1D Itqk8xPmUvAM8kUi+8EgogWrPlfKQIu/Fqu4v0MEotTS/w60/mY01DSV0lLnAB3XLU5W TaRW/a7OgfSGDvnwd5OosIG6bzCcslbv4B2evuxMBZSvyeuEG5jJKZO3eM46glIl9Mxa SC8CtZUuKtXF4+nYUwBHgV5e92EBltneIDKyZLVQRiFG4ztpvzAOlWR828LucW8tp7+O /yhw==
X-Gm-Message-State: AOUpUlG8oCu3SWBvQZytINM6mznA9X/XqZu0sP8rJVwT9BaszBlysboS JLpq6+BSrkdw/Mrmy4sUgi4lJm/iyCFuSUiOinGisOQ=
X-Google-Smtp-Source: AAOMgpfpHpibSweW2yLXakBbx62x6T+dfzk9xeCDCZtAcUIT69F5GgBT7FH87oeQYPYfqJVc38zzSPS/x6SqDtuGs8Y=
X-Received: by 2002:ab0:4c6c:: with SMTP id d44-v6mr15777680uag.102.1532550730801; Wed, 25 Jul 2018 13:32:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a67:3348:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 13:32:09 -0700 (PDT)
In-Reply-To: <5ee9c290-39c0-83d7-e182-9a34d139583a@spamtrap.tnetconsulting.net>
References: <1cb82914-0bc3-9ea7-7f69-9dc826d19e48@andreasschulze.de> <2264d840-33cc-736c-668a-a537c4da4a30@nic.cz> <alpine.DEB.2.20.1807241623300.5965@grey.csi.cam.ac.uk> <CADyWQ+HZ4i2P9qK03xK_EvZYakdduKigH87QgZ4zfUwjHjL25Q@mail.gmail.com> <5B574F67.1090806@redbarn.org> <993209cf-01b5-c6c2-cc64-74b42c398e26@spamtrap.tnetconsulting.net> <alpine.DEB.2.20.1807251209520.3596@grey.csi.cam.ac.uk> <5ee9c290-39c0-83d7-e182-9a34d139583a@spamtrap.tnetconsulting.net>
From: Scott Morizot <tmorizot@gmail.com>
Date: Wed, 25 Jul 2018 15:32:09 -0500
Message-ID: <CAFy81rkVceaod42ig5Az2OhjGDjNj71TFwaQYtiOHuuuW1c2HA@mail.gmail.com>
To: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e8e63c0571d8c5d9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RQhPDKMBQPKQytoScRQ6BCqwJ2M>
Subject: Re: [DNSOP] howto "internal"
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 25 Jul 2018 20:32:16 -0000
On<gtaylor=40tnetconsulting.net@dmarc.ietf.org> wrote: > On 07/25/2018 05:18 AM, Tony Finch wrote: > >> I recommend having an empty public view of your private zone, so that >> external queries succeed with NXDOMAIN / NODATA. >> > > ACK. > > What is your opinion on blindly grafting the sub-domain onto the parent > zone without proper delegation. I.e. internal DNS server hosts > internal.example.net and external DNS server returns NXDOMAIN for > internal.example.net. > > I have my doubts about this sort of scheme supporting DNSSEC. - I think > it would be better to have a mostly empty zone that is properly delegated > that re-use the same DNSSEC keys. > > I might even go so far as to have the external server be a slave for a > specific empty view transferred from the internal server. That way the > keys stay internal. > > It may leak some information, but I do think that the hard NXDOMAIN / >> NODATA is likely cleanest for the DNS protocol. >> > A true "internal" enterprise network with entirely private DNS zones will often have distinct authoritative nameservers for the private versions of zones, distinct internal recursive nameservers, and will restrict clients on the enterprise network from accessing any recursive nameservers outside the enterprise network. The decisions I've made for my employer's architecture reflect those requirements and preconditions. We also DNSSEC sign most authoritative zones and DNSSEC validate responses on all recursive nameservers. With those conditions, every zone needs to be rooted in an officially registered and delegated domain to support proper chain of trusts with valid secure or insecure delegations as appropriate. With those conditions in mind, most zones (domains and subdomains within a tree) are designated as either public or internal/private. At the point where a delegated subdomain shifts to internal, a public placeholder version of the zone is created. While we have multiple registered second level domains, we have two primary second level domains that also support our enterprise. One of them is, for all practical purposes, entirely private. So only a second level zone placeholder is public. The other is public at the second level and third level (and lower) domains are a mix of public and private. Third level zone that represent the top of an internal zone hierarchy off that second level domain tree all have a public placeholder. At the demarcation point where a domain in the tree shifts to private (typically the second level domain in one case and at a number of the third level domains in the other) the DS records for both the public placeholder and the private version of the zone are placed in the public parent zone. Whether the placeholder or the real version of the zone is resolved, an appropriately signed DS record for a key signing the DNSKEY RRSet can always be resolved. Given the complex, layered nature of our recursive DNS infrastructure we used forward zones and default forwarders within the enterprise itself. Our Internet/extranet recursive configuration is also more complex than even most enterprises. Yes, trust anchors are an alternative within the standard in the absence of valid delegations or when "fake" TLDs are used, but those are not really manageable at a large enterprise scale. We do use them to anchor RFC1918 reverse arpa zones with our own versions. That's relatively straightforward, but I wouldn't want to attempt it on any broader basis. Admittedly, the above represents a DNS architecture supporting a large, highly restricted enterprise network. But in any architecture where DNSSEC validation is a factor, the chain of trust will always need to be considered. We also do employ RPZ. And we do break DNSSEC (and have encountered at least one malware domain that was DNSSEC signed). We're fine with DNSSEC validation failing for responses we've rewritten to block with RPZ. Our key considerations are that the query will not go out to the Internet and the client will not get a response from the Internet. Failed validation at the client if it should validate or SERVFAIL from a lower level nameserver to the client are perfectly acceptable results from our perspective. Scott
- Re: [DNSOP] howto "internal" Petr Špaček
- [DNSOP] howto "internal" A. Schulze
- Re: [DNSOP] howto "internal" Ted Lemon
- Re: [DNSOP] howto "internal" Paul Vixie
- Re: [DNSOP] howto "internal" Tony Finch
- Re: [DNSOP] howto "internal" Tim Wicinski
- Re: [DNSOP] howto "internal" Joe Abley
- Re: [DNSOP] howto "internal" Paul Vixie
- Re: [DNSOP] howto "internal" Tim Wicinski
- Re: [DNSOP] howto "internal" Grant Taylor
- Re: [DNSOP] howto "internal" Grant Taylor
- Re: [DNSOP] howto "internal" Tony Finch
- Re: [DNSOP] howto "internal" Grant Taylor
- Re: [DNSOP] howto "internal" Scott Morizot
- Re: [DNSOP] howto "internal" Tony Finch