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 _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
