On<gtaylor=40tnetconsulting....@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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
