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 <s...@andreasschulze.de> 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
