Re: allow-query and views
On 02/21/2013 02:16 PM, Vernon Schryver wrote:
The ARM says in part:
Built-in server information zones
The server provides some helpful diagnostic information through a
number of built-in zones under the pseudo-top-level-domain bind
in the CHAOS class. These zones are part of a built-in view (see
the section called "view Statement Grammar") of class CHAOS which
is separate from the default view of class IN; therefore, any
global server options such as allow-query do not apply the these
zones. If you feel the need to disable these zones, use the options
below, or hide the built-in CHAOS view by defining an explicit
view of class CHAOS that matches all clients.
Now that I read what I wrote, I see that it's wrong.
I found and just now verified that options{allow-query{}} affects
the _bind view at least in 9.10.0pre-alpha with the rrl and rpz2
patches. I found that feature (or perhap bug) when I decided to
stop hiding the version I use lest anyone think I don't do what I
advocate with BIND patches.
I don't know whether the bug is in the ARM or the code. If you
pick one, I can argue the other.
Well my named.conf now has in general options:
allow-query{ localhost; };
allow-query-cache{ localhost; };
recursion no;
And no access to the chaos zone from my testing out on the internet.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
On 02/21/2013 02:04 PM, Vernon Schryver wrote: From: Robert Moskowitz Whow... This is news. A hidden view? Where is this documented. The ARM says in part: Built-in server information zones The server provides some helpful diagnostic information through a number of built-in zones under the pseudo-top-level-domain bind in the CHAOS class. These zones are part of a built-in view (see the section called "view Statement Grammar") of class CHAOS which is separate from the default view of class IN; therefore, any global server options such as allow-query do not apply the these zones. If you feel the need to disable these zones, use the options below, or hide the built-in CHAOS view by defining an explicit view of class CHAOS that matches all clients. Oy vey, through a glass darkly. Pieces come back to me about things I learned when Kevin introduced me to bind back in '93 and since then I have only delved into it when I did an upgrade (like right now!). I missed Chaosnet, I was doing X.25 stuff around then. Of course use it for odds and ends these days. And I seemed to have tighted up my rules real tight. In the global options I have locked down queries to only localhost, then open it up in the views. I just tested externally and no access to chaos now. Here is the log entry: Feb 21 14:14:37 onlo named[24803]: client 70.194.0.112#9517: query 'version.bind/TXT/CH' denied I have no restrictions in my general options section. Figured that the specific view ones were all that was needed. Now I am upset. It's not a real view, because that you can't change it except by editing the BIND source, using the version, hostname, and server-id options, hiding it as the ARM says, or with default options. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
> The ARM says in part:
>
> Built-in server information zones
> The server provides some helpful diagnostic information through a
> number of built-in zones under the pseudo-top-level-domain bind
> in the CHAOS class. These zones are part of a built-in view (see
> the section called "view Statement Grammar") of class CHAOS which
> is separate from the default view of class IN; therefore, any
> global server options such as allow-query do not apply the these
> zones. If you feel the need to disable these zones, use the options
> below, or hide the built-in CHAOS view by defining an explicit
> view of class CHAOS that matches all clients.
Now that I read what I wrote, I see that it's wrong.
I found and just now verified that options{allow-query{}} affects
the _bind view at least in 9.10.0pre-alpha with the rrl and rpz2
patches. I found that feature (or perhap bug) when I decided to
stop hiding the version I use lest anyone think I don't do what I
advocate with BIND patches.
I don't know whether the bug is in the ARM or the code. If you
pick one, I can argue the other.
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
On 02/21/2013 01:54 PM, Matus UHLAR - fantomas wrote:
On 21.02.13 12:45, Robert Moskowitz wrote:
Fact:
No clients could access DNS from my server, both internal and
external (I have hotspot on my cellphone, so I can attach a client to
it to get external testing) UNTIL I added the allow-query option.
Once added things started working right.
Which BIND version do you use?
Centos 6.3 which Redhat has bind 9.8.2 with patches they have included;
most notably the security patches.
Do you use your own named.conf? Some OSes/distributions provide multiple
included files with some defaults that may deny access, for example.
Are you sure your named.conf doesn't include such file?
Yes, I have crafted the named.conf and all of its includes. It was at
first a port of what I was running on Centos 5.5 which was bind 9.3.6
(thus before the changes wrought by by 9.4.1.P1). I added a few items
from the default named.conf that came with Centos 6.3, notably the
DNSSEC and support for port randomization (instead of set to 53).
All I can report is what was not working and what made it work.
allow-query SEEMS to be working the same way as allow-query-cache.
but they both do different things.
I get that. But I had neither, thus living with the defaults. Adding
'allow-query { httnet;}' got my local clients working again, and to any
for when I was testing via my cellular connection.
Check my earlier posts here. I was down here with just the
match-clients and without the allow-query; all local hosts were
getting denied access. It was painful for a little while.
Probably they did not have a recursion enabled. allow-recursion
defaults
to local networks, if not specified directly or by allow-query-cache.
I had the recursion yes option in my internal view. But even queries
of zones it was master for were coming up DENIED without the
allow-query option.
There's something strange about this issue. The default for
allow-query is
"all" and I don't think this was different any time.
Are you sure there's no other "allow-query" directive anywhere in your
named's config files?
No. None. There was a commented one that came with the default, but it
was commented out. It WAS set to localhost, but again it was commented out.
Recursion seems to be working with just "recursion yes" here.
Recursion by itself, yes. But the default for allow-recursion might
not be
enough for you.
In fact, you can use "allow-recursion { all; };" and still only
internal
clients (in internal view) would have it allowed.
So "recursion yes" does not override "allow-recursion"? Strange.
recursion yes/no will tell the server (not) to recurse at all.
allow-recursion only specifies, for whom to recurse.
"recursion no" will disable recursing for all (matching) clients.
"recursion yes" will enable recursing, but only for allowed clients.
So for my external zone with "recursion no", I can leave off the
"allow-recursion".
What does allow-recursion add with given all the other restrictive
clauses?
It allows specified clients to use recursion. Both allow-query-cache
and
allow-recursion default to the other one, when only one is specified.
However, allow-recursion gives a better idea of what is really allowed.
Then what is the basic recursion option for now? Is it just a
hold-over from more trusting days?
it's kind of general switch to allow/deny recursion.
GOt it. Thanks.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
> From: Robert Moskowitz > Whow... This is news. A hidden view? Where is this documented. The ARM says in part: Built-in server information zones The server provides some helpful diagnostic information through a number of built-in zones under the pseudo-top-level-domain bind in the CHAOS class. These zones are part of a built-in view (see the section called "view Statement Grammar") of class CHAOS which is separate from the default view of class IN; therefore, any global server options such as allow-query do not apply the these zones. If you feel the need to disable these zones, use the options below, or hide the built-in CHAOS view by defining an explicit view of class CHAOS that matches all clients. >I > have no restrictions in my general options section. Figured that the > specific view ones were all that was needed. Now I am upset. It's not a real view, because that you can't change it except by editing the BIND source, using the version, hostname, and server-id options, hiding it as the ARM says, or with default options. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
On 21.02.13 12:45, Robert Moskowitz wrote:
Fact:
No clients could access DNS from my server, both internal and
external (I have hotspot on my cellphone, so I can attach a client to
it to get external testing) UNTIL I added the allow-query option.
Once added things started working right.
Which BIND version do you use?
Do you use your own named.conf? Some OSes/distributions provide multiple
included files with some defaults that may deny access, for example.
Are you sure your named.conf doesn't include such file?
All I can report is what was not working and what made it work.
allow-query SEEMS to be working the same way as allow-query-cache.
but they both do different things.
Check my earlier posts here. I was down here with just the
match-clients and without the allow-query; all local hosts were
getting denied access. It was painful for a little while.
Probably they did not have a recursion enabled. allow-recursion defaults
to local networks, if not specified directly or by allow-query-cache.
I had the recursion yes option in my internal view. But even queries
of zones it was master for were coming up DENIED without the
allow-query option.
There's something strange about this issue. The default for allow-query is
"all" and I don't think this was different any time.
Are you sure there's no other "allow-query" directive anywhere in your
named's config files?
Recursion seems to be working with just "recursion yes" here.
Recursion by itself, yes. But the default for allow-recursion might not be
enough for you.
In fact, you can use "allow-recursion { all; };" and still only internal
clients (in internal view) would have it allowed.
So "recursion yes" does not override "allow-recursion"? Strange.
recursion yes/no will tell the server (not) to recurse at all.
allow-recursion only specifies, for whom to recurse.
"recursion no" will disable recursing for all (matching) clients.
"recursion yes" will enable recursing, but only for allowed clients.
What does allow-recursion add with given all the other restrictive
clauses?
It allows specified clients to use recursion. Both allow-query-cache and
allow-recursion default to the other one, when only one is specified.
However, allow-recursion gives a better idea of what is really allowed.
Then what is the basic recursion option for now? Is it just a
hold-over from more trusting days?
it's kind of general switch to allow/deny recursion.
--
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.
I don't have lysdexia. The Dog wouldn't allow that.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
On 02/21/2013 12:58 PM, Mike Hoskins (michoski) wrote: -Original Message- From: Robert Moskowitz Date: Thursday, February 21, 2013 12:53 PM To: Vernon Schryver Cc: "bind-users@lists.isc.org" Subject: Re: allow-query and views Whow... This is news. A hidden view? Where is this documented. I have no restrictions in my general options section. Figured that the specific view ones were all that was needed. Now I am upset. As usual, knowledge is easy but wisdom takes time... http://www.cymru.com/Documents/secure-bind-template.html It will take much time to gain wisdom from this piece of advice, as it does not answer questions about the hidden view Vern mentioned. It does address the chaos part; in part. You can easily incorporate that before Passover. :-) Hah! That is what you think! Perhaps we can talk about this at IETF? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
-Original Message- From: Robert Moskowitz Date: Thursday, February 21, 2013 12:53 PM To: Vernon Schryver Cc: "bind-users@lists.isc.org" Subject: Re: allow-query and views >Whow... This is news. A hidden view? Where is this documented. I >have no restrictions in my general options section. Figured that the >specific view ones were all that was needed. Now I am upset. As usual, knowledge is easy but wisdom takes time... http://www.cymru.com/Documents/secure-bind-template.html You can easily incorporate that before Passover. :-) hth ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
On 02/21/2013 11:50 AM, Vernon Schryver wrote:
correct, no external hosts should query your cache.
OK.
There is no substitute for testing assumptions, mailing list assurances,
understandings of documentation, etc. Test from outside your network
to see that your DNS servers don't answer requests they shouldn't and
answer those they should as they should (e.g. with(out) consulting the
cache).
I have external testing via my Verizon phone's WiFi hotspot. Very handy.
Don't forget to check `dig @whatever chaos txt version.bind` whether
your preference is to publish your version, hostname, and server-ID
or not. Restrictions such as allow-query{} in the main options{}
statement can turn off the hidden "_bind" view defined in
bin/named/config.c.
Whow... This is news. A hidden view? Where is this documented. I
have no restrictions in my general options section. Figured that the
specific view ones were all that was needed. Now I am upset.
https://www.google.com/search?q=dig+command+web
finds at least three web pages with loose enough parsing to allow not
only simply requests for A records but poking at chaos, so you don't
need to pay for a shell account somewhere or rely on charity.
thanks
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
On 02/21/2013 12:10 PM, Matus UHLAR - fantomas wrote:
On 21.02.13 08:59, Robert Moskowitz wrote:
I am reading: https://www.isc.org/software/bind/faq and 'What has
changed in the behavior of "allow-recursion" and
"allow-query-cache" '.
I am struggling here trying to match up the various access control
features, particularly when we are suppose to have different views
for different clients.
So for my internal view where I:
match-clients{ httnets; };
match-destinations{ httnets; };
recursion yes;
allow-query{ httnets; };
On 02/21/2013 10:40 AM, Matus UHLAR - fantomas wrote:
allow-query is useless here, unless you have disabled it somewhere.
the match-clients does enough.
On 21.02.13 11:08, Robert Moskowitz wrote:
No. allow-query made my internal view available to my local clients.
allow-query defaults to all. match-clients directs your internal
clients to
the internal view and unless you have disabled querying elsewhere,
allowing
it is not important.
Fact:
No clients could access DNS from my server, both internal and external
(I have hotspot on my cellphone, so I can attach a client to it to get
external testing) UNTIL I added the allow-query option. Once added
things started working right.
All I can report is what was not working and what made it work.
allow-query SEEMS to be working the same way as allow-query-cache.
Check my earlier posts here. I was down here with just the
match-clients and without the allow-query; all local hosts were
getting denied access. It was painful for a little while.
Probably they did not have a recursion enabled. allow-recursion
defaults to
local networks, if not specified directly or by allow-query-cache.
I had the recursion yes option in my internal view. But even queries of
zones it was master for were coming up DENIED without the allow-query
option.
Do I also add
allow-query-cache{ httnets; };
???
you apparently want to turn on recursion for your clients, which
means, you
should use "allow-recursion" and let allow-query-cache be teh same by
default.
Recursion seems to be working with just "recursion yes" here.
Recursion by itself, yes. But the default for allow-recursion might
not be
enough for you.
In fact, you can use "allow-recursion { all; };" and still only internal
clients (in internal view) would have it allowed.
So "recursion yes" does not override "allow-recursion"? Strange.
What does allow-recursion add with given all the other restrictive
clauses?
It allows specified clients to use recursion. Both allow-query-cache and
allow-recursion default to the other one, when only one is specified.
However, allow-recursion gives a better idea of what is really allowed.
Then what is the basic recursion option for now? Is it just a hold-over
from more trusting days?
And for the external view where:
match-clients{ any; };
match-destinations{ any; };
allow-query{ any; };
recursion no;
Do I add:
allow-query-cache{ localhost; };
thanks
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
On 21.02.13 08:59, Robert Moskowitz wrote:
I am reading: https://www.isc.org/software/bind/faq and 'What has
changed in the behavior of "allow-recursion" and
"allow-query-cache" '.
I am struggling here trying to match up the various access
control features, particularly when we are suppose to have
different views for different clients.
So for my internal view where I:
match-clients{ httnets; };
match-destinations{ httnets; };
recursion yes;
allow-query{ httnets; };
On 02/21/2013 10:40 AM, Matus UHLAR - fantomas wrote:
allow-query is useless here, unless you have disabled it somewhere.
the match-clients does enough.
On 21.02.13 11:08, Robert Moskowitz wrote:
No. allow-query made my internal view available to my local clients.
allow-query defaults to all. match-clients directs your internal clients to
the internal view and unless you have disabled querying elsewhere, allowing
it is not important.
Check my earlier posts here. I was down here with just the
match-clients and without the allow-query; all local hosts were
getting denied access. It was painful for a little while.
Probably they did not have a recursion enabled. allow-recursion defaults to
local networks, if not specified directly or by allow-query-cache.
Do I also add
allow-query-cache{ httnets; };
???
you apparently want to turn on recursion for your clients, which
means, you
should use "allow-recursion" and let allow-query-cache be teh same by
default.
Recursion seems to be working with just "recursion yes" here.
Recursion by itself, yes. But the default for allow-recursion might not be
enough for you.
In fact, you can use "allow-recursion { all; };" and still only internal
clients (in internal view) would have it allowed.
What does allow-recursion add with given all the other restrictive
clauses?
It allows specified clients to use recursion. Both allow-query-cache and
allow-recursion default to the other one, when only one is specified.
However, allow-recursion gives a better idea of what is really allowed.
And for the external view where:
match-clients{ any; };
match-destinations{ any; };
allow-query{ any; };
recursion no;
Do I add:
allow-query-cache{ localhost; };
--
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.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
> > correct, no external hosts should query your cache.
> >
> OK.
There is no substitute for testing assumptions, mailing list assurances,
understandings of documentation, etc. Test from outside your network
to see that your DNS servers don't answer requests they shouldn't and
answer those they should as they should (e.g. with(out) consulting the
cache).
Don't forget to check `dig @whatever chaos txt version.bind` whether
your preference is to publish your version, hostname, and server-ID
or not. Restrictions such as allow-query{} in the main options{}
statement can turn off the hidden "_bind" view defined in
bin/named/config.c.
https://www.google.com/search?q=dig+command+web
finds at least three web pages with loose enough parsing to allow not
only simply requests for A records but poking at chaos, so you don't
need to pay for a shell account somewhere or rely on charity.
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
On 02/21/2013 10:40 AM, Matus UHLAR - fantomas wrote:
On 21.02.13 08:59, Robert Moskowitz wrote:
I am reading: https://www.isc.org/software/bind/faq and 'What has
changed in the behavior of "allow-recursion" and "allow-query-cache" '.
I am struggling here trying to match up the various access control
features, particularly when we are suppose to have different views
for different clients.
So for my internal view where I:
match-clients{ httnets; };
match-destinations{ httnets; };
recursion yes;
allow-query{ httnets; };
allow-query is useless here, unless you have disabled it somewhere.
the match-clients does enough.
No. allow-query made my internal view available to my local clients.
Check my earlier posts here. I was down here with just the
match-clients and without the allow-query; all local hosts were getting
denied access. It was painful for a little while.
Do I also add
allow-query-cache{ httnets; };
???
you apparently want to turn on recursion for your clients, which
means, you
should use "allow-recursion" and let allow-query-cache be teh same by
default.
Recursion seems to be working with just "recursion yes" here. What
does allow-recursion add with given all the other restrictive clauses?
And for the external view where:
match-clients{ any; };
match-destinations{ any; };
allow-query{ any; };
recursion no;
Do I add:
allow-query-cache{ localhost; };
??? Supposedly localhost will fall into the internal view (along
with httnet)
and does localhost belong to the httnets ACL?
Yes. both 127.0.0.1 and ::1 are listed.
, so nothing should be querying cache?
correct, no external hosts should query your cache.
OK.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
On 21.02.13 08:59, Robert Moskowitz wrote:
I am reading: https://www.isc.org/software/bind/faq and 'What has
changed in the behavior of "allow-recursion" and "allow-query-cache"
'.
I am struggling here trying to match up the various access control
features, particularly when we are suppose to have different views
for different clients.
So for my internal view where I:
match-clients{ httnets; };
match-destinations{ httnets; };
recursion yes;
allow-query{ httnets; };
allow-query is useless here, unless you have disabled it somewhere.
the match-clients does enough.
Do I also add
allow-query-cache{ httnets; };
???
you apparently want to turn on recursion for your clients, which means, you
should use "allow-recursion" and let allow-query-cache be teh same by
default.
And for the external view where:
match-clients{ any; };
match-destinations{ any; };
allow-query{ any; };
recursion no;
Do I add:
allow-query-cache{ localhost; };
??? Supposedly localhost will fall into the internal view (along
with httnet)
and does localhost belong to the httnets ACL?
, so nothing should be querying cache?
correct, no external hosts should query your cache.
--
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.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows. -- Matthew D. Fuller
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
allow-query and views
I am reading: https://www.isc.org/software/bind/faq and 'What has
changed in the behavior of "allow-recursion" and "allow-query-cache" '.
I am struggling here trying to match up the various access control
features, particularly when we are suppose to have different views for
different clients.
So for my internal view where I:
match-clients{ httnets; };
match-destinations{ httnets; };
recursion yes;
allow-query{ httnets; };
Do I also add
allow-query-cache{ httnets; };
???
And for the external view where:
match-clients{ any; };
match-destinations{ any; };
allow-query{ any; };
recursion no;
Do I add:
allow-query-cache{ localhost; };
??? Supposedly localhost will fall into the internal view (along with
httnet), so nothing should be querying cache?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
