[BBLISA] Forgoing internal dns?

[John Miller]

On 05/29/2013 07:47 AM, Daniel Feenberg wrote:
>
>
> On Wed, 29 May 2013, John Miller wrote:
>
>> Hi everyone,
>>
>> 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).  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.
>>
>
> Wouldn't you want to use a vendor that would allow you to maintain a
> slave server, or would be a slave to your server? Route 53 doesn't seem
> to allow this, or at least doesn't mention it, but wouldn't another
> vendor do so? A caching nameserver couldn't promise to have every record
> for every local resource in its cache, but a slave would.

My thinking exactly.  We can't guarantee that a given entry will be 
cached.  We can up the odds by using large TTLs, but something won't be 
cached if it's not queried fairly often.  A record's importance isn't 
always in proportion to how frequently it's queried, either.  We need to 
be thinking "what are the consequences of not having this record?" 
Painful consequences = important record.

If we do guarantee that something's cached, then we're running a de 
facto authoritative DNS anyhow.

>
> If the vendor server was a slave to your master, then there would be
> minimal vendor lock-in. If the vendor has only a propieary API or GUI,
> it will be difficult to switch vendors.
>

Again, you've read my mind.  Vendor lock-in isn't something I'm eager to 
promote.

John

> daniel feenberg
> NBER