[BBLISA] Forgoing internal dns?

[John Miller]

On 05/29/2013 02:48 AM, Bill Bogstad wrote:
> I'm not exactly sure what your situation/what you are trying to
> accomplish; but even
> given that; this strikes me as a bad idea.  Some thoughts:
>

The overall goal is to revamp our authoritative DNS, hosting part of it 
with a cloud provider, who can handle queries from off-campus better 
than we can do.  Management has suggested not running on-campus 
authoritative DNS, save for a few limited cases.

> 1. Are those 100M/month queries coming from local or remote clients?
> If they are mostly local, do you really want to push that traffic over
> your WAN rather
> then your on-campus LAN?   If only for latency if not bandwith
> concerns.  (Based on the
> size of the entry returned for www.brandeis.edu, I calculate around
> 500 Mbytes a day which
> probably isn't a big deal; but you should check my figures.)

Hi Bill, and thanks for responding.  Most of these 100M/month queries 
are authoritative queries coming from our internal resolvers.  I'd 
certainly prefer not to push the traffic over the campus WAN--latency is 
definitely higher across the Internet than if it stays on campus. 
You're right, however, that overall bandwidth is not a huge concern--DNS 
isn't exactly a chatty protocol.

>
> 2. What's your churn on DNS entries?   A quick look makes me think
> that Amazon's Route
> 53 is designed for high traffic on a a moderate number of entires.
> Not the 1000s? of entries
> you might have for all of the devices on campus.   How easy is it
> going to be to integrate what
> ever you use on campus to create entries to feed entries to Amazon?
>

Our entry churn isn't as high as one might think.  I'd guess that we 
add/update/delete 10 A records a week, so perhaps 25 if you figure in 
reverse records and CNAMEs.  We run dynamic dns (BIND), both from Active 
Directory DCs publishing SRV records, and our main DHCP servers (ISC) 
sending updates based on our network registration system.

I also agree with you that Route 53 is really more tailored toward 
moderate numbers of entries that can be managed by hand.  We'd be at 
several thousand entries without breaking a sweat; far more if you 
include the dynamic stuff we host locally.

We would have to run a local sync process to make sure that our cloud 
records agree with one another, so we'd have to write custom code to 
make it work.

> 3. You already mentioned concerns about caching nameservers when your
> WAN link is down.
> I agree with this concern.
>
> 4. Have you analyzed your DNS traffic to see if changing your TTLs
> could reduce the number
> of requests to a more manageable level?
>

TTLs certainly could help things out--there's no reason we need to have 
1-hour TTLs on largely static records.  There are also probably some 
300-second TTLs out there that never got changed back post-change.

We'd probably like to be running low TTLs for a select few records--DNS 
failover pretty much demands this.

> 5. Have you thought about doing to a "hidden master" or "hidden
> secondary" DNS setup. i.e.
> Requests from off campus would go to a DNS provider, while on-campus
> machines would talk
> to the local servers.
>

This is exactly the scenario I'd like to go with.  Off-campus requests 
stay that way; requests from on campus only go off-campus in an emergency.

Good GUI editing tools aren't as plentiful as you'd think, however, so 
it makes a certain amount of sense to use a cloud provider as a 
quasi-hidden master, just syncing records between the cloud and a local 
master server.

John

> Good Luck,
> Bill Bogstad
>