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
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
In article ,
Michael Monnerie 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
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 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
> > allow-query-cache is not set then
> > allow-recursion is used if set, otherwise
> > allow-query is used if set unless
> > recursion no; is set in which case
> > none; is used, otherwise the default
> > (localnets; localhost;) 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
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
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 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
On Donnerstag 01 Oktober 2009 Mark Andrews wrote: > Specifies which hosts are allowed to get answers > from the cache. If > allow-query-cache is not set then > allow-recursion is used if set, otherwise > allow-query is used if set unless > recursion no; is set in which case > none; is used, otherwise the default > (localnets; localhost;) 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 -- // 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
Have you read the documentation that describes what allow-query does?
allow-query
Specifies which hosts are allowed to ask ordinary
DNS questions. allow-query may
also be specified in the zone
statement, in which case it overrides the
options allow-query statement.
If not specified, the default is to allow queries
from all hosts.
allow-query-cache is now
used to specify access to the cache.
allow-query-cache
Specifies which hosts are allowed to get answers
from the cache. If allow-query-cache
is not set then allow-recursion
is used if set, otherwise allow-query
is used if set unless recursion no; is
set in which case none; is used,
otherwise the default (localnets;
localhost;) is used.
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 #1039:
> >> view watchdog: query (cache) 'www.google.de/A/IN' denied
> >> Sep 30 14:21:40 gw named[28715]: 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
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 #1039:
view watchdog: query (cache) 'www.google.de/A/IN' denied
Sep 30 14:21:40 gw named[28715]: 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
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 #1039: view watchdog: query (cache) 'www.google.de/A/IN' denied Sep 30 14:21:40 gw named[28715]: 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
Query Refused problem
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 #1039: view watchdog: query (cache) 'www.google.de/A/IN' denied Sep 30 14:21:40 gw named[28715]: 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
