allow-query and views

[Robert Moskowitz]

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?

[Matus UHLAR - fantomas]

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

[Robert Moskowitz]

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.

[Vernon Schryver]

> > 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 Schryver v...@rhyolite.com

[Matus UHLAR - fantomas]

>>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

[Robert Moskowitz]

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

[Robert Moskowitz]

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

[Mike Hoskins (michoski)]

-----Original Message-----

From: Robert Moskowitz <r...@htt-consult.com>
Date: Thursday, February 21, 2013 12:53 PM
To: Vernon Schryver <v...@rhyolite.com>
Cc: "bind-...@lists.isc.org" <bind-...@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

[Robert Moskowitz]

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?

[Matus UHLAR - fantomas]

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.

[Vernon Schryver]

> From: Robert Moskowitz <r...@htt-consult.com>

> 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 Schryver v...@rhyolite.com

[Robert Moskowitz]

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.

[Vernon Schryver]

> 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 Schryver v...@rhyolite.com

[Robert Moskowitz]

On 02/21/2013 02:04 PM, Vernon Schryver wrote:
>> From: Robert Moskowitz <r...@htt-consult.com>
>> 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

[Robert Moskowitz]

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.