> From: [email protected] [mailto:[email protected]] On > Behalf Of John Miller > > I've been meaning to bring this up at the previous meetings, but > haven't. Brandeis is looking to move all authoritative DNS out to a cloud > provider (Route 53's currently the leading candidate).
I am, in recent years, definitely promoting this. With IPv6 coming, now is a good time to start getting prepared. The concept of "internal" and "external" simply go away. In present day security, you maintain a private network, and a perimeter around that network. But you permit authorized users to access the whole private network when their traffic comes in via VPN. Which means (a) it's authenticated, and (b) it's encrypted. In the future of IPv6, you're going to do the same exact thing, but authentication and encryption are built into the protocol itself. So you in fact *do* literally take your internal services and expose them to the internet. The same as you presently do with IPv4 over VPN. Peoples' active directory domains, in the past, very often *.local domains. This needs to be eliminated in favor of world-resolvable DNS domains. You can maintain split DNS if you need to. > We definitely should > be doing this on some level--an external provider can give better latency and > uptime than we could ever dream of providing ourselves. > However, a problem arises: we still have tons of internal services--Active > Directory, financial aid, management servers, print servers, file servers, (I > could go on)--that live directly in our main domain. The terms "external" and > "internal" don't exactly apply in our case--everything's a bit of both. > > Without hosting some sort of authoritative services within our network, we'd > have to rely on our caching nameservers to answer queries during network > downtime. Think of your UPS situation. Server with redundant power supplies. One side plugs into UPS, other side plugs into surge protector. So you keep power if your UPS blows up, and you keep power if your UPS is online while the upstream power source is off. Build your caching DNS server, and configure clients to use it first, and 8.8.8.8 (or whatever) second. It's important that your caching name server is first, so things will actually *be* cached in the event the upstream becomes unavailable. If you just want to make sure the "internal" domain is cached, you can make your caching name server the secondary for local clients to use, and make it a backup provider for the master which is offsite. So it's actually authoritative (it is guaranteed to know your domain, even though the upstream might be unavailable and nothing recently cached locally). But you manipulate the remote master server, which then replicates down to your backup server. _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
