Re: [DNSOP] howto "internal"

Scott Morizot <> Wed, 25 July 2018 20:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7282A130E0A for <>; Wed, 25 Jul 2018 13:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i5Ja5w3A3pkH for <>; Wed, 25 Jul 2018 13:32:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EDC812E039 for <>; Wed, 25 Jul 2018 13:32:12 -0700 (PDT)
Received: by with SMTP id p22-v6so5954027uao.7 for <>; Wed, 25 Jul 2018 13:32:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <>
References: <> <> <> <> <> <> <> <>
From: Scott Morizot <>
Date: Wed, 25 Jul 2018 15:32:09 -0500
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000e8e63c0571d8c5d9"
Archived-At: <>
Subject: Re: [DNSOP] howto "internal"
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Jul 2018 20:32:16 -0000

On<> 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
> and external DNS server returns NXDOMAIN for
> 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

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.