On 05/29/2013 07:26 AM, Edward Ned Harvey (bblisa4) wrote: > 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. >
Thanks, Ed. We're only just now beginning to take IPv6 into account network-wide, so it isn't a large concern at the moment. Since you suggest using a world-resolvable DNS domain for Active Directory, do you suggest using a subdomain of our main domain? We aren't using Active Directory for DNS, so using our main domain causes some problems. > >> 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. > We're definitely quite redundant in our caching layer--we have several vms and hardware servers, running different daemons, spread across campus. It would definitely go against the grain to move a copy of our authoritative records back onto our caching servers, especially since they're caching-only. Makes us a little more vulnerable to cache poisoning, plus some of our servers really are caching-only. It's something I hadn't considered much, but you've got me thinking a bit. John _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
