Query Refused problem

[Mark Andrews]

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.9000204 at 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 at lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/bind-users
> > 
> > _______________________________________________
> > bind-users mailing list
> > bind-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> 
> _______________________________________________
> bind-users mailing list
> bind-users at 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: marka at isc.org