Have you read the documentation that describes what allow-query does?
<varlistentry>
<term><command>allow-query</command></term>
<listitem>
<para>
Specifies which hosts are allowed to ask ordinary
DNS questions. <command>allow-query</command> may
also be specified in the <command>zone</command>
statement, in which case it overrides the
<command>options allow-query</command> statement.
If not specified, the default is to allow queries
from all hosts.
</para>
<note>
<para>
<command>allow-query-cache</command> is now
used to specify access to the cache.
</para>
</note>
</listitem>
</varlistentry>
<varlistentry>
<term><command>allow-query-cache</command></term>
<listitem>
<para>
Specifies which hosts are allowed to get answers
from the cache. If <command>allow-query-cache</command>
is not set then <command>allow-recursion</command>
is used if set, otherwise <command>allow-query</command>
is used if set unless <command>recursion no;</command> is
set in which case <command>none;</command> is used,
otherwise the default (<command>localnets;</command>
<command>localhost;</command>) is used.
</para>
</listitem>
</varlistentry>
Mark
In message <4ac36444.9000...@whgl.uni-frankfurt.de>, Sven Eschenberg writes:
> Dear list,
>
> This seems more tricky, then I thought.
>
> When I had no allow-query statement at all in my config, everything
> worked find (includign recursion) for all clients, that were in subnets
> directly attached to the server. The external view (authoriative, non
> recursive) did work for every client as supposed to.
> Now a client on a not directly attached subnet, with it's own view,
> could not resolve anything, except local zones on the server. (Though
> recursion was turned on for the view).
> External view's clients could nto recurse, though recursion was turned
> on, obviously to realyl recurse I'd need an allow-query statement.
>
> Adding an allow-query statement to the general config, limitied to the
> campus network made all local views work, but with the result, that no
> client matching the external view could looks up the authoriative zones.
>
> Now, I am wondering if I did set uop everything right afterall, here's
> what I did do:
>
> External view, no recursion, allow-query {any;}
> Not directly attached client with internal view: match on client's ip,
> allow recursion, allow query for the client's ip.
> all other internal views, matched by locally attached netowrks, no
> allow-query statement, allow recursion.
>
> This seems to work.
>
> I am wondering: Would it be harmfull to allow queries by any host
> (globally) as long as external clients (in their view) are not allowed
> any recursion? Would that be more feasible?
>
> Regards
>
> -Sven
>
>
> Sven Eschenberg schrieb:
> > I got it fixxed with an allow-query statement.
> >
> > But this arises another question: Does bind implicitly add allow-queries
> > for locally attached interfaces and the networks configured for these?
> >
> > I am asking, because it used to work for all the subnets directly
> > attached to the machine.
> >
> > Regards
> >
> > -Sven
> >
> > Sven Eschenberg schrieb:
> >> Dear list,
> >>
> >> I have one client with a specific zone. When the client does a query
> >> for localhost on the nameserver, or a reverse lookup for 127.0.0.1,
> >> everything seems perfectly okay. As soon, as the client tries to
> >> lookup i.e. google.de or any external ip, I am getting query refused
> >> errors.
> >>
> >> Sep 30 14:21:40 gw named[28715]: client <ip of matched client>#1039:
> >> view watchdog: query (cache) 'www.google.de/A/IN' denied
> >> Sep 30 14:21:40 gw named[28715]: client <ip of matched client>#1040:
> >> view watchdog: query (cache) 'www.google.de/A/IN' denied
> >>
> >> The DNS-Server works as a recursor for the client.
> >>
> >> What puzzles me most is: I cloned another internal view, which works
> >> perfectly well for the clients matched by it.
> >>
> >> What might I be missing here, what can trigger a query refused answer
> >> like this?
> >>
> >> Regards
> >>
> >> -Sven
> >>
> >>
> >> _______________________________________________
> >> bind-users mailing list
> >> bind-users@lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/bind-users
> >
> > _______________________________________________
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> _______________________________________________
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
