Re: [DNSOP] howto "internal"
Grant Taylor wrote: > > What is your opinion on blindly grafting the sub-domain onto the parent zone > without proper delegation. Asking for trouble. We used to do that in the dim and distant past but not any more because it's incompatible with DNSSEC. > As I type this I wonder about delegating to RFC 1918 address via names in an > NS record that are within delegated zone. Thus they would require glue > records. Externally I'd omit the glue records. Internally I'd have the > records within zone scope along with all the other zone data. > > I suspect that this may cause odd retry issues too. Yes. However, if you are willing to have views in the parent public zone, you might as well omit the private delegation entirely in the public version. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher, German Bight, Humber: East 3 or 4 veering southeast 4 or 5, increasing 6 at times. Slight, becoming slight or moderate later. Thundery showers developing. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] howto "internal"
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 > 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
Re: [DNSOP] howto "internal"
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. Returning REFUSED for a private zone causes retries, and not responding at all causes even worse problems such as EDNS fallback attempts. ACK I haven't tried delegating to RFC1918 addresses, but that is likely to cause similar weirdness. As I type this I wonder about delegating to RFC 1918 address via names in an NS record that are within delegated zone. Thus they would require glue records. Externally I'd omit the glue records. Internally I'd have the records within zone scope along with all the other zone data. I suspect that this may cause odd retry issues too. It may leak some information, but I do think that the hard NXDOMAIN / NODATA is likely cleanest for the DNS protocol. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] howto "internal"
Grant Taylor wrote: > > Is there a best practice around this method of delegating to sub-domain(s) > that are inaccessible to the public? I recommend having an empty public view of your private zone, so that external queries succeed with NXDOMAIN / NODATA. Returning REFUSED for a private zone causes retries, and not responding at all causes even worse problems such as EDNS fallback attempts. I haven't tried delegating to RFC1918 addresses, but that is likely to cause similar weirdness. Tony. -- f.anthony.n.finchhttp://dotat.at/ Bailey: South 3 or 4, becoming cyclonic 5 to 7, occasionally gale 8 for a time. Slight or moderate, becoming rough or very rough. Rain. Moderate or poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] howto "internal"
Paul, On 07/24/2018 10:10 AM, Paul Vixie wrote: i also use real domains for my private stuff. but i also use RPZ locally for the internal bindings, Do you leverage anything like Dynamic DNS updates in conjunction with DHCP? If so, how well does that play with the configuration that you're using? not NS RR delegations that i'd have to keep out of my externally-served zone files. Is there a best practice around this method of delegating to sub-domain(s) that are inaccessible to the public? Is it better to return NODATA or NXDOMAIN to global clients querying for host.sub-domain.example.net? Or is there a different error that can be returned to indicate no access? I guess there's always delegating to a server that is inaccessible externally too. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] howto "internal"
On 07/24/2018 09:08 AM, Petr Špaček wrote: I would recommend you to use subdomain of your public domain. Agreed. The alternative might be to use a different public domain. Nice thing is that this approach doesn't require: - views - forwarding - explicit trust anchor (if you want DNSSEC inside internal network) Public (sub)domain(s) also make it easier to use external / 3rd party CAs. - Rather I've found it difficult to use private / non-public (sub)domain(s) when using public CAs. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] howto "internal"
Tim Wicinski wrote: At my employer we use real domains, but do not expose them to the outside world (they just see 127.0.0.1). It's a better than inverting security through obscurity like I have seen elsewhere (not that you would do that Andreas). Paul, I am not with 100% love of the .alt name./idea but I do agree that if we don't do something the Real Users (tm) will do something even more broken and horrific. i also use real domains for my private stuff. but i also use RPZ locally for the internal bindings, not NS RR delegations that i'd have to keep out of my externally-served zone files. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] howto "internal"
Hi Andreas, One problem with using non-unique namesapaces is that if you ever find yourself needing to join your infrastructure to someone else's you run the risk of collisions. [This is an analogue to the problem at the IP layer with using RFC 1918 addresses -- if I'm already using 192.168.1.0/24 and so is the other person, either one of us needs to renumber or we need a world of translation complexity to be able to talk to each other.] My usual answer to your question is to register a domain for internal use and name everything within it. You can make the DNS records available to your internal resolver and not even delegate the zone in the public DNS if you like. The point of the registration is just uniqueness. Using a subdomain of a name you already use is a functionally-equivalent answer, but it involves some degree of change to domain names you already use. Even if this is clearly low-cost today, it might add unwelcome complexity in the future. There are many more angles to the wider discussion about new TLDs like internal, alt, etc or using names under example.com, but in your case since you get to start from scratch I think a few dollars per year to reserve a unique name is a cheap and good answer. Joe > On Jul 24, 2018, at 10:52, A. Schulze wrote: > > Hello, > > some times ago there was an proposal (?) from Warren Kumari to define a zone > "internal." for internal use. > > We consider a major DNS redesign of a large enterprise network. Part of the > network is private (RFC1918 address space in use) > some other parts are public. The whole network is currently organized as > subdomains of example.com. > > One problem is the inability of users to distinguish the public/private state > of different subdomains. > sub1.example.com is public, sub2.example.com isn't :-/ > > For that I like the proposal to use "internal." But that's far away from > being a standard. > So I like to ask about alternatives... > > Thanks for suggestions > Andreas > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] howto "internal"
At my employer we use real domains, but do not expose them to the outside world (they just see 127.0.0.1). It's a better than inverting security through obscurity like I have seen elsewhere (not that you would do that Andreas). Paul, I am not with 100% love of the .alt name./idea but I do agree that if we don't do something the Real Users (tm) will do something even more broken and horrific. Tim On Tue, Jul 24, 2018 at 11:32 AM, Tony Finch wrote: > Petr Špaček wrote: > > > > My operational experience indicates that it is easiest to just use > > "corp.example.com.", "office.example.com.", or even "i.example.com.". > > We use private.cam.ac.uk. > > > Nice thing is that this approach doesn't require: > > - views > > We have an empty version of private.cam.ac.uk in an external view, > originally set up to avoid problems with CAA checking for X.509 > certificates. It also massively reduces retries for REFUSED queries from > outside. (Our qps went down by about 50% when we introduced this view!) > > > - forwarding > > However you do still need forwarding (or stealth secondarying) for RFC1918 > reverse DNS. Catalog zones make stealth secondaries almost as easy as > forwarding to set up and maintain :-) > > > - explicit trust anchor (if you want DNSSEC inside internal network) > > > > and generally just works :-) > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Sole: Westerly backing southerly, 3 or 4, increasing 5 or 6 later in west.. > Slight, becoming moderate in west. Mainly fair. Moderate or good. > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] howto "internal"
Petr Špaček wrote: > > My operational experience indicates that it is easiest to just use > "corp.example.com.", "office.example.com.", or even "i.example.com.". We use private.cam.ac.uk. > Nice thing is that this approach doesn't require: > - views We have an empty version of private.cam.ac.uk in an external view, originally set up to avoid problems with CAA checking for X.509 certificates. It also massively reduces retries for REFUSED queries from outside. (Our qps went down by about 50% when we introduced this view!) > - forwarding However you do still need forwarding (or stealth secondarying) for RFC1918 reverse DNS. Catalog zones make stealth secondaries almost as easy as forwarding to set up and maintain :-) > - explicit trust anchor (if you want DNSSEC inside internal network) > > and generally just works :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Sole: Westerly backing southerly, 3 or 4, increasing 5 or 6 later in west. Slight, becoming moderate in west. Mainly fair. Moderate or good.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] howto "internal"
It would probably be easier to get internal.arpa, similar to home.arpa. You could use home.arpa now, but it would look a little funny... :) On Tue, Jul 24, 2018 at 10:52 AM, A. Schulze wrote: > Hello, > > some times ago there was an proposal (?) from Warren Kumari to define a > zone "internal." for internal use. > > We consider a major DNS redesign of a large enterprise network. Part of > the network is private (RFC1918 address space in use) > some other parts are public. The whole network is currently organized as > subdomains of example.com. > > One problem is the inability of users to distinguish the public/private > state of different subdomains. > sub1.example.com is public, sub2.example.com isn't :-/ > > For that I like the proposal to use "internal." But that's far away from > being a standard. > So I like to ask about alternatives... > > Thanks for suggestions > Andreas > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
