Re: Query Refused problem
On 01.10.09 19:10, Sven Eschenberg wrote:
Funny enough, I did not have any allow-query at all, but adding
allow-query {any;} did indeed change the behavior. But
allow-query-cache obviously defaults to localhost, localnets and was
triggering the behavior that confused me.
Matus UHLAR - fantomas schrieb:
OK, again: did you have any other allows ?
Which means allow-recursion, allow-query-cache
On 02.10.09 11:18, Sven Eschenberg wrote:
recursion yes; - does this fall into the same category by any chanc? I
used it in some views ecplicitly.
no.
I really wander how could using allow-query help anything, since it
defaults to any;. I thought there's something misconfigured on your
server...
--
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.
Despite the cost of living, have you noticed how popular it remains?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Query Refused problem
On Freitag 02 Oktober 2009 Mark Andrews wrote:
if (set(allow-query-cache))
use allow-query-cache;
else if (set(allow-recursion))
use allow-recursion;
else if (set(allow-query))
use allow-query;
else if (set(recursion no;))
use { none; };
else
use { localnets; localhost; };
Ah, it's always an elseif. That wasn't clear to me. Easier to read C
than english, am I a nerd? ;-)
Maybe it's because I'm not native English, but the paragraph is very
confusing. A simpler wording would surely help others as well.
Thank you Mark!
mfg zmi
--
// Michael Monnerie, Ing.BSc- http://it-management.at
// Tel: 0660 / 415 65 31 .network.your.ideas.
// PGP Key: curl -s http://zmi.at/zmi.asc | gpg --import
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Query Refused problem
In article mailman.649.1254472597.14796.bind-us...@lists.isc.org,
Michael Monnerie michael.monne...@is.it-management.at wrote:
On Freitag 02 Oktober 2009 Mark Andrews wrote:
if (set(allow-query-cache))
use allow-query-cache;
else if (set(allow-recursion))
use allow-recursion;
else if (set(allow-query))
use allow-query;
else if (set(recursion no;))
use { none; };
else
use { localnets; localhost; };
Ah, it's always an elseif. That wasn't clear to me. Easier to read C
than english, am I a nerd? ;-)
Maybe it's because I'm not native English, but the paragraph is very
confusing. A simpler wording would surely help others as well.
I second that and I'm a native English speaker. I've also been looking
at rearranging our DNS recently and the same logic defeated me.
Sam
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Query Refused problem
Matus UHLAR - fantomas schrieb:
On 01.10.09 19:10, Sven Eschenberg wrote:
Funny enough, I did not have any allow-query at all, but adding
allow-query {any;} did indeed change the behavior. But allow-query-cache
obviously defaults to localhost, localnets and was triggering the
behavior that confused me.
OK, again: did you have any other allows ?
Which means allow-recursion, allow-query-cache
recursion yes; - does this fall into the same category by any chanc? I
used it in some views ecplicitly.
Aside from that only allow-transfer statements for slaves.
Regards
-Sven
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Query Refused problem
On 30.09.09 15:59, Sven Eschenberg wrote:
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?
allow-query { any; }; is default. Do you have any other allows's ?
the first error message indicated that you didn't allow query-cache or recursion
for some clients. Apparently you cloned a view but forget to allow either
one in the new view...
--
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.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watson. -- Daffy Duck Porky Pig
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Query Refused problem
Funny enough, I did not have any allow-query at all, but adding
allow-query {any;} did indeed change the behavior. But allow-query-cache
obviously defaults to localhost, localnets and was triggering the
behavior that confused me.
Inbetween I overhauled the config, setting all the options explicitly
where needed, instead of building on default behavior and everything
works as expected now. Lessen learned: Ignore defaults, always set
things as YOU want them to be :-).
Thanks for your reply though.
Regards
-Sven
Matus UHLAR - fantomas schrieb:
On 30.09.09 15:59, Sven Eschenberg wrote:
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?
allow-query { any; }; is default. Do you have any other allows's ?
the first error message indicated that you didn't allow query-cache or recursion
for some clients. Apparently you cloned a view but forget to allow either
one in the new view...
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Query Refused problem
On 01.10.09 19:10, Sven Eschenberg wrote:
Funny enough, I did not have any allow-query at all, but adding
allow-query {any;} did indeed change the behavior. But allow-query-cache
obviously defaults to localhost, localnets and was triggering the
behavior that confused me.
OK, again: did you have any other allows ?
Which means allow-recursion, allow-query-cache
Inbetween I overhauled the config, setting all the options explicitly
where needed, instead of building on default behavior and everything
works as expected now. Lessen learned: Ignore defaults, always set
things as YOU want them to be :-).
Could you post your config (and optional includes) somewhere?
I still thinkthe real problem lied elsewhere...
Matus UHLAR - fantomas schrieb:
On 30.09.09 15:59, Sven Eschenberg wrote:
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?
allow-query { any; }; is default. Do you have any other allows's ?
the first error message indicated that you didn't allow query-cache or
recursion
for some clients. Apparently you cloned a view but forget to allow either
one in the new view...
--
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.
Microsoft dick is soft to do no harm
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Query Refused problem
In message 200910011237.09...@zmi.at, Michael Monnerie writes:
On Donnerstag 01 Oktober 2009 Mark Andrews wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Specifies which hosts are allowed to =
get answers
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 from the cache. =A0If
commandallow-query-cache/command is not set then
commandallow-recursion/command is used if set, otherwise
commandallow-query/command is used if set unless
commandrecursion no;/command is set in which case
commandnone;/command is used, otherwise the default
(commandlocalnets;/command commandlocalhost;/command) is
used.
Not exactly a good explanation. At least, I've read it twice and still =
don't exactly know where the if..else..elseif... parts connect. Maybe =
someone could change that to pseudocode with if statements, or make it =
several sentences so it's clear where if..unless..except..otherwise =
parts start and end.
mfg zmi
-- =
if (set(allow-query-cache))
use allow-query-cache;
else if (set(allow-recursion))
use allow-recursion;
else if (set(allow-query))
use allow-query;
else if (set(recursion no;))
use { none; };
else
use { localnets; localhost; };
// Michael Monnerie, Ing.BSc- http://it-management.at
// Tel: 0660 / 415 65 31 .network.your.ideas.
// PGP Key: curl -s http://zmi.at/zmi.asc | gpg --import
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
___
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
Re: Query Refused problem
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
Re: Query Refused problem
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
Re: Query Refused problem
Have you read the documentation that describes what allow-query does?
varlistentry
termcommandallow-query/command/term
listitem
para
Specifies which hosts are allowed to ask ordinary
DNS questions. commandallow-query/command may
also be specified in the commandzone/command
statement, in which case it overrides the
commandoptions allow-query/command statement.
If not specified, the default is to allow queries
from all hosts.
/para
note
para
commandallow-query-cache/command is now
used to specify access to the cache.
/para
/note
/listitem
/varlistentry
varlistentry
termcommandallow-query-cache/command/term
listitem
para
Specifies which hosts are allowed to get answers
from the cache. If commandallow-query-cache/command
is not set then commandallow-recursion/command
is used if set, otherwise commandallow-query/command
is used if set unless commandrecursion no;/command is
set in which case commandnone;/command is used,
otherwise the default (commandlocalnets;/command
commandlocalhost;/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
