On Fri, Oct 21, 2016 at 6:21 PM, David Birdsong <da...@imgix.com> wrote:

>
> I'd love to hear how others are handling the overhead of managing two dns
> providers. Every time we brainstorm on it, we see it as blackhole of eng
> effort WRT to keeping them in sync and and then waiting for TTLs to cut an
> entire delegation over.
>


with the usual caveats - and I dont have any projects that currently need
this but have in the past - pretty much every major dns provider allows you
to ship them a full zone in some form or fashion.   The effort to pull and
ship a zone should be fairly minimal in and of itself.

mixing your public zone providers in your authoritative NS records is also
easy - and, depending on your registrar of choice, should be easy to manage
changing those (including having non-public mirrors maintained that you can
switch too..).   setting TTLs that make sense for a design that supports
change is also easy.

the real developmental and architectural challenges are around what to do
if the APIs you use to talk to your "primary" disappear and you need to
consume them (creating new host entries, updating loadbalancer pools,
whatever.  we all have different and sometimes very diverse use cases for
dns.).

one approach - as randy suggested - is to switch to a purely hidden and
self managed primary - which might mean running your own API stack in front
of it to control whatever you need to control and change.   this doesnt
need to be a "real" dns server in todays world - the days of BIND style
zone transfers are generally long gone anyway when you hit these scales and
levels of intra complexity.    then your zone-replication components that
ship zone updates to your various external providers are shipping from the
same place.

at least in that case it's fully within your control - but dev time and
complexity definitely comes into play.

if your infra can survive internally without dns change control for the
extent of an outage, that could be much easier to manage.

anyway, random and incomplete thoughts - time ran out, work calls.


...david

Reply via email to