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
