In article <mailman.13.1519170108.3031.bind-us...@lists.isc.org>, "Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:
> Other than the master server(s), where there is no choice but to be > authoritative, at one end of the spectrum, and border resolvers, for which > there is no choice but to be non-authoritative (since it's not practical to > replicate data for the vast diversity of namespaces on the Internet in which > to resolve queries), at the other end of the spectrum, there is a middle > ground, where there is a real *choice* as to whether to be authoritative > (i.e. a slave, possibly a "stealth slave") for internal zones or not. The > decision of whether to be authoritative or not, is driven by a number of > factors, such as worst-case-query-performance sensitivity, availability > requirements, query-frequency-versus-refresh-overhead, available bandwidth, > DNSSEC, etc. It is perfectly reasonable, architecturally, for a given DNS > instance to be a stealth slave for some zones and to either delegate, stub > and/or forward for other zones, or for the default to be one or the other > (auth-server as default implies having an internal root). Different zones > have different requirements, different use cases, query patterns, etc. so why > wouldn't a choice of different configurations for different zones be > appropriate? Being authoritative for your own zones, and recursive for everything else, is generally not a big problem. The problemat case is service providers being authoritative for customer domains and using the same servers for caching. What often happens is that a customer switches to another DNS provider, but doesn't inform their old provider. As a result, all the other customers who use these caching servers continue to get the obsolete version of this customer's domains. When I worked at an ISP a couple of decades ago, I wrote a script that periodically checked the delegations of all the domains we hosted, to make sure they still pointed to us. -- Barry Margolin Arlington, MA _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
