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