questions on allow-query

Barry Margolin barmar at alum.mit.edu
Wed Feb 21 17:41:41 UTC 2018


In article <mailman.13.1519170108.3031.bind-users at lists.isc.org>,
 "Darcy Kevin (FCA)" <kevin.darcy at 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


More information about the bind-users mailing list