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
