On 2013-03-14, at 08:21, "R.P. Aditya" <[email protected]> wrote:
> I didn't mean to be opaque, but just in case it clarifies more: > > The question is "does the benefit of quicker updates outweigh the risks > involved in serving a few select zones authoritatively from a recursive > server that is open to a select population?" Hosting authoritative zones on recursive servers is recommended for zones that are recognised as being for local use, e.g. see RFC 6303. There is nothing fundamentally broken with this idea. What you're suggesting (if I read the inference correctly) is that your recursive servers are also acting as stealth slaves for particular zones that your user base cares about, zones that are not of only local significance in the 6303 sense. The only risk I can think of that you might consider is that of troubleshooting in the future. You need to make sure that the stealth slaves are able to maintain up-to-date copies of those zones (i.e. that zone transfer is working) to avoid the confusing situation where clients of your recursive servers are seeing a different zone revision from the one published on the non-stealth authoritative servers (i.e. the servers that are cited in the delegation and apex NS sets). For example, consider a situation where someone else in the organisation decides in the future to change the hosting of those zones, but is unaware of the stealth slave arrangement on the recursive servers. The zones might move and zone transfers of those zones might start to fail, and the result might very well be an apparently complex and mysterious situation that it is not immediately obvious how to debug. You might consider whether it makes any practical difference to your users in terms of performance or stability for these zones to be served authoritatively by your caches or whether the caches actually cache answers from external authoritative servers depends. I won't presuppose an answer to that question, since it depends on an understanding of your particular circumstances and I don't think there's any useful general answer. > I do realize that that is a determination for my organization to make, > but if more of the risks were enumerated for non-open resolvers, it > would be easier to weigh. The operational concern above is all I can think of, if I've understood the question correctly. Joe _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
