[BBLISA] Forgoing internal dns?

[John Miller]

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