View-specific logging
I would like to switch on query logging for specific views only. Is this possible using BIND 9.7 (or any other BIND version, for that matter)? The "querylog" option does not seem to apply to views, and it does not appear to be possible to filter based on view in the "logging" phrase. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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
Re: About root zones
On 21.12.11 19:21, Peter Andreev wrote: All these servers are slaves. They don't send notifies. 2011/12/21 Matus UHLAR - fantomas : they do, unless you have turned it off... On 22.12.11 11:54, Peter Andreev wrote: Of course I turned it off, it's normal practice for slaves, I assume. even sending notifies by slaves can have a reason. for example, other slaves not getting notifies from master... Do you think if server needed to resolve something, and you would disable it, it would work better? I think just the oposite. If a server does lookups only when needed, then disabling required lookups would make it not working. I think that if server is authoritative - and - slave-only it should use system resolver rather than querying by itself. BIND will not use system resolver. BIND is the resolver. Relying on other resolver could cause troubles. If BIND does not need to resolve, it will not. If it needs, don't block it. Where can I find information about what causes queries for internal duties? If it can be found in ARM, could you please point me to the right chapter. May be I missed something while reading it. The only mention I have met is that additional resolving is needed for sending notifies (And will this resolving be performed in case of list of slaves' ip addresses is written in named.conf?). Someone other will have to answer this. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod ___ 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
Re: About root zones
2012/1/2 Matus UHLAR - fantomas : >>> On 21.12.11 19:21, Peter Andreev wrote: All these servers are slaves. They don't send notifies. > > >> 2011/12/21 Matus UHLAR - fantomas : >>> >>> they do, unless you have turned it off... > > > On 22.12.11 11:54, Peter Andreev wrote: >> >> Of course I turned it off, it's normal practice for slaves, I assume. > > > even sending notifies by slaves can have a reason. for example, other slaves > not getting notifies from master... > > >>> Do you think if server needed to resolve something, and you would disable >>> it, it would work better? I think just the oposite. If a server does >>> lookups >>> only when needed, then disabling required lookups would make it not >>> working. > > >> I think that if server is authoritative - and - slave-only it should >> use system resolver rather than querying by itself. > > > BIND will not use system resolver. BIND is the resolver. Relying on other > resolver could cause troubles. If BIND does not need to resolve, it will > not. If it needs, don't block it. > I understood your point, however it differs from mine. Matus, I'm afraid we won't find consent on this topic. So I offer you to stop this discussion. Thank you for suggestions and happy new year! > >> Where can I find information about what causes queries for internal >> duties? If it can be found in ARM, could you please point me to the >> right chapter. May be I missed something while reading it. The only >> mention I have met is that additional resolving is needed for sending >> notifies (And will this resolving be performed in case of list of >> slaves' ip addresses is written in named.conf?). > > > Someone other will have to answer this. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > Spam = (S)tupid (P)eople's (A)dvertising (M)ethod > > ___ > 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 -- -- AP ___ 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
Re: About root zones
On 21.12.11 19:21, Peter Andreev wrote:
I think that if server is authoritative - and - slave-only it should
use system resolver rather than querying by itself.
2012/1/2 Matus UHLAR - fantomas :
BIND will not use system resolver. BIND is the resolver. Relying on other
resolver could cause troubles. If BIND does not need to resolve, it will
not. If it needs, don't block it.
On 02.01.12 16:42, Peter Andreev wrote:
I understood your point, however it differs from mine.
Matus, I'm afraid we won't find consent on this topic. So I offer you
to stop this discussion.
Thank you for suggestions and happy new year!
I don't see your point now. I'm afraid that you will have to live with
the fact that you can not disable sending queries from BIND when it
needs them, you can only prevent it by configuring BIND (so it will not
need them) or firewall such packets so they will not get outside (which
may break its functionality).
Maybe ISC will patch BIND to use system resolver for internal queries,
but I doubt so. Maybe you can do it but imho it's not worth trying.
Maybe you can set up forward only; and forwarders {}; so BIND will
forward all recursive queries it generates to your recursive servers.
But the way you are trying to get over this, I'm afrait you will fail
and that's what I am trying to tell you.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
How does cat play with mouse? cat /dev/mouse
___
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
Re: About root zones
On 1/2/2012 5:42 AM, Matus UHLAR - fantomas wrote: On 21.12.11 19:21, Peter Andreev wrote: All these servers are slaves. They don't send notifies. 2011/12/21 Matus UHLAR - fantomas : they do, unless you have turned it off... On 22.12.11 11:54, Peter Andreev wrote: Of course I turned it off, it's normal practice for slaves, I assume. even sending notifies by slaves can have a reason. for example, other slaves not getting notifies from master... Do you think if server needed to resolve something, and you would disable it, it would work better? I think just the oposite. If a server does lookups only when needed, then disabling required lookups would make it not working. I think that if server is authoritative - and - slave-only it should use system resolver rather than querying by itself. BIND will not use system resolver. BIND is the resolver. Relying on other resolver could cause troubles. If BIND does not need to resolve, it will not. If it needs, don't block it. I agree with Matus. BIND should be as self-sufficient as possible, and not make any assumptions about the capability of and/or the data it expects to get from the system resolver, which might be configured to look at a completely different DNS namespace, or be configured with non-DNS resolution methods, be broken with respect to IPv4/IPv6 capabilities, address sorting, etc. There's lot that can go wrong when you make one subsystem (BIND-based DNS) dependent on another (system resolver, however that's set up, if it's set up at all). BIND already has ways to resolve names, and many different ways to precisely control how it does that, so it shouldn't be necessary to rely on a completely different subsystem for that function. Now, what are your real complaints about an authoritative-only nameserver making "internal" queries? Looking back through the thread, I think there are two: 1) That internal lookups are generated when sending NOTIFYs. Do you actually need to send those NOTIFYs, or are you just leaving things with the default configuration (which follows the RFC 1996 algorithm of looking at the contents of the zone's NS records and its SOA.MNAME)? If you need those NOTIFYs at all, I expect that you could suppress the associated lookups with a combination of "also-notify" and "notify explicit". Then BIND only has a list of IP addresses to which to send NOTIFYs and I can't (offhand) see any reason for it to generate "internal" lookups. I haven't tested this theory, but it shouldn't be hard to do. Another thing to consider: even with the default NOTIFY behavior, named shouldn't need to generate lookups for any of the names associated with the NOTIFYs which are in zones for which it is authoritative. E.g. if you're authoritative for example.com and ns1.example.com is a name within that zone, then you shouldn't need to generate a lookup for that name if you want to send a NOTIFY to it. Moreover, since NS targets tend to "cluster" within groups of zones under common administrative control, it should only be a fairly small minority of NS targets which require internal lookups for NOTIFY purposes. Is this really a problem then? 2) "upwards referrals". If your recursion-disabled nameserver is configured to respond to queries outside of its authoritative zones, then the typical response would be an "upwards referral" to the root zone. But to give good, current information about the root zone, when the root zone is explicitly or implicitly defined with only "hints", a "priming" query needs to be made when named starts up (since "hints" are only "hints", not the real data, which is obtained by querying the roots). Someone mentioned defining your own root zone authoritatively with localhost as the only root nameserver. But that's a really bad idea if you're giving out upwards referrals to arbitrary Internet resolvers. You could poison the cache of some really old, broken nameserver. The link that David Forrest gave to a DNS-OARC webpage pretty much runs down the whole "upwards referral" issue, and I recommend you read it. You could combine defining your own root zone authoritatively (which will suppress the priming query), with carefully controlling access to that zone (as described on that webpage) so that no upwards referrals are given. I wouldn't recommend populating that root zone with "garbage" (such as localhost, for example); I'd put real root-zone information in there, just in case the ACLs in named.conf get accidentally reconfigured some day (perhaps by whomever inherits your config). That root-zone data gets stale over time, of course, but it takes many many years for it to become completely invalid, and if you're concerned about that, you could write a simple script to do a root zone query periodically (e.g. monthly) and refresh the contents of the zone file. Or, you could just let ISC do the work of compiling the latest root-zone data into each version of BIND
Re: About root zones
In article , Kevin Darcy wrote: > I agree with Matus. BIND should be as self-sufficient as possible, and > not make any assumptions about the capability of and/or the data it > expects to get from the system resolver If the system resolver is good enough for every other application running on the system, it should be good enough for BIND. Why not at least allow this as an option? -- 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
Re: About root zones
On Jan 2, 2012, at 2:16 PM, Barry Margolin wrote: > If the system resolver is good enough for every other application > running on the system, it should be good enough for BIND. > > Why not at least allow this as an option? The system resolver will happily provide answers based upon data from /etc/hosts, YP/NIS, and LDAP which have no relationship to what is in the DNS. Every other application on the system is probably not a DNS nameserver. Case in point: should dig use the system resolver for an /etc/hosts entry and pretend that there was an A and PTR record in the DNS? Regards, -- -Chuck ___ 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
Re: About root zones
On 01/02/2012 11:16, Barry Margolin wrote: > In article , > Kevin Darcy wrote: > >> I agree with Matus. BIND should be as self-sufficient as possible, and >> not make any assumptions about the capability of and/or the data it >> expects to get from the system resolver > > If the system resolver is good enough for every other application > running on the system, it should be good enough for BIND. > > Why not at least allow this as an option? +1 Given that there exist today name server solutions that are authoritative-only, it makes sense that BIND 9 should have a knob to do this. Also, consider the potential harm of cache poisoning when the features are mixed. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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
Re: About root zones
In article , Chuck Swiger wrote: > On Jan 2, 2012, at 2:16 PM, Barry Margolin wrote: > > If the system resolver is good enough for every other application > > running on the system, it should be good enough for BIND. > > > > Why not at least allow this as an option? > > The system resolver will happily provide answers based upon data from > /etc/hosts, YP/NIS, and LDAP which have no relationship to what is in the > DNS. In that case, you probably shouldn't enable the option. I'm not even suggesting that the option be on by default. Actually, does libresolv really use those other facilities? gethostbyname() does, but BIND probably shouldn't use that, because it loses data like TTLs. > Every other application on the system is probably not a DNS nameserver. Case But a DNS nameserver is not the same thing as a DNS client. > in point: should dig use the system resolver for an /etc/hosts entry and > pretend that there was an A and PTR record in the DNS? Of course not, since the purpose of dig is to test DNS queries and show the internal details. -- 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
