Re: [DNSOP] howto "internal"

[Scott Morizot <[e-mail]>]

On<gtaylor=[e-mail]> 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