Hello, I am a little confused about the security settings allow-query
and allow recursion and was hoping someone might be able to clear my
confusion.  I am currently testing this on a BIND 9.3.0 linux box.

An acl line of "allow-query { our-nets; };" would globally only allow
queries from our designated IP's but deny queries from everyone else,
correct?
With the acl line above and with the line "allow-query { any; };" in a
zone it would then allow this zone to be queried from anyone in the
world.  Basically overriding the global setting but only on this zone.

From my understanding the "allow recursion", enables or disables boxes
from looking up domains that this box doesn't handle the zones for.
So an acl line like "allow-recursion { our-nets; };" would only allow
IP's within our network to lookup other domains and block everyone
else from querying some domain, right?

In the BIND manual -
http://www.bind9.net/manual/bind/9.2.3/Bv9ARM.ch07.html they have the
statement

"acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24;
224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
acl our-nets { x.x.x.x/24; x.x.x.x/21; };
options {
allow-query { our-nets; };
allow-recursion { our-nets; };
blackhole { bogusnets; };
};
zone "example.com" {
type master;
file "m/example.com";
allow-query { any; };
};
This allows recursive queries of the server from the outside unless
recursion has been previously disabled."

^^ that line is a typo right?  This disables recursive queries not
enabling them, right?

As a test I set I set BIND to only allow-queries from our-nets but
commented out allow-recursion. So something like
acl our-nets { x.x.x.x/24; x.x.x.x/21; };
options {
allow-query { our-nets; };
#  allow-recursion { our-nets; };
blackhole { bogusnets; };
};
For some reason I still see denies in our logs.  What exactly is being
denied if we are allowing recursion?  Here is a snippet from our logs
20-Jun-2007 12:16:32.246 security: client XXX.XXX.XXX.XXX#32772: query
(cache) 'NPICEF136.domaintest.com/A/IN' denied

Thanks,
Nick

[ Post a follow-up to this message ]

On 20 Jun 2007, at 17:33, Nick wrote:

> Hello, I am a little confused about the security settings allow-query
> and allow recursion and was hoping someone might be able to clear my
> confusion.  I am currently testing this on a BIND 9.3.0 linux box.
>
> An acl line of "allow-query { our-nets; };" would globally only allow
> queries from our designated IP's but deny queries from everyone else,
> correct?
> With the acl line above and with the line "allow-query { any; };" in 
a
> zone it would then allow this zone to be queried from anyone in the
> world.  Basically overriding the global setting but only on this zone.
>
> From my understanding the "allow recursion", enables or disables boxes
> from looking up domains that this box doesn't handle the zones for.
> So an acl line like "allow-recursion { our-nets; };" would only allow
> IP's within our network to lookup other domains and block everyone
> else from querying some domain, right?

You hardly seem confused at all!  8-)

You may be overlooking referral responses.  A query for DNS data
contained in a zone not carried on your box and from an address
for which you have chosen to accept requests but to deny recursion
will result in a referral to "name servers which have zones which
are closer ancestors to the name [requested] than the server [your
box] sending the reply" [RFC1034, p.23].


Best regards,

Niall O'Reilly
University college Dublin IT Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

[ Post a follow-up to this message ]

In article <f5blac$1roq$1@sf1.isc.org>, Nick <kvetch@gmail.com> wrote:

> An acl line of "allow-query { our-nets; };" would globally only allow
> queries from our designated IP's but deny queries from everyone else,
> correct?
> With the acl line above and with the line "allow-query { any; };" in 
a
> zone it would then allow this zone to be queried from anyone in the
> world.  Basically overriding the global setting but only on this zone.
>
> From my understanding the "allow recursion", enables or disables boxes
> from looking up domains that this box doesn't handle the zones for.
> So an acl line like "allow-recursion { our-nets; };" would only allow
> IP's within our network to lookup other domains and block everyone
> else from querying some domain, right?

The main difference is that if someone is not in the "allow-recursion"
ACL they'll be allowed to query data that is already in your server's
cache.  So if an internal user looks up www.google.com, external users
will be able to look this up until the cached record expires (and in the
case of a popular name like this, it will probably be in cache most of
the time).

BIND 9.4 adds a new option, I think called "allow-query-cache", that
does what most people wanted "allow-recursion" to do.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ Post a follow-up to this message ]

> In article <f5blac$1roq$1@sf1.isc.org>, Nick <kvetch@gmail.com> wrote:
> 
>
> The main difference is that if someone is not in the "allow-recursion"
> ACL they'll be allowed to query data that is already in your server's
> cache.  So if an internal user looks up www.google.com, external users
> will be able to look this up until the cached record expires (and in the
> case of a popular name like this, it will probably be in cache most of
> the time).
>
> BIND 9.4 adds a new option, I think called "allow-query-cache", that
> does what most people wanted "allow-recursion" to do.

allow-query-cache just seperated out what allow-query
operated on.  allow-query now only affects zones rather
than zones and cache.

You could always prevent people querying the cache.  It was
just more work if you were also offically authoritative for
a zone as you needed to add "allow-query {any;};" to the
zone definition.

Seperately you now need to match both allow-query-cache
and allow-recursion to have RA set in responses.

Mark

> --
> Barry Margolin, barmar@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***
> *** PLEASE don't copy me on replies, I'll read them in the group ***
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

[ Post a follow-up to this message ]

Barry Margolin wrote:
> In article <f5blac$1roq$1@sf1.isc.org>, Nick <kvetch@gmail.com> wrote:
> 
>
> The main difference is that if someone is not in the "allow-recursion"
> ACL they'll be allowed to query data that is already in your server's
> cache.  So if an internal user looks up www.google.com, external users
> will be able to look this up until the cached record expires (and in
> the case of a popular name like this, it will probably be in cache
> most of the time).


> BIND 9.4 adds a new option, I think called "allow-query-cache", that
> does what most people wanted "allow-recursion" to do.

Doesn't setting

recursion no;

do that too?

--
CL

[ Post a follow-up to this message ]

On 21/6/07 1:14 PM, "Clenna Lumina" <savagebeaste@yahoo.com> wrote:

>
> Doesn't setting
>
>    recursion no;
>
> do that too?
No, I'll elaborate below from the 9.4 ARM:

"allow-recursion

Note that disallowing recursive queries for a host does not prevent the host
from retrieving data that is already in the server's cache."

and

"recursion

Note that setting recursion no does not prevent clients from getting
data from the server's cache; it only prevents new data from being cached as
an effect of client queries. Caching may still occur as an effect the
server's internal operation, such as NOTIFY address lookups."

So we now use:

"allow-query-cache

Specifies which hosts are allowed to get answers from the cache. The
default is the builtin acls localnets and localhost. "


HTH





--
Kal Feher

[ Post a follow-up to this message ]

Ah, thanks Niall.  So does the allow-query { our-nets; }; also block
any queries for domains we don't specifically have zones for?  I
thought that is what the recursion directive is for.
If I don't set allow recursion to our-nets, meaning recursion is
allowed I still can't do lookups on other zones it isn't the authority
for (I did the lookup from an IP not in our-net).  I get REFUSED flag
back.
# dig @192.168.1.1 yahoo.com
; <<>> DiG 9.3.4 <<>> @192.168.1.1 yahoo.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 41420
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;yahoo.com.                  IN      A
;; Query time: 14 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Jun 21 11:26:04 2007
;; MSG SIZE  rcvd: 30

To make sure there wasn't something screwy with my named.conf, I
captured the packets when doing the lookup and I see the Flag is set
that states Server Can Do Recursive Queries.  What is blocking the
lookup then?  Does having allow-queries to our-nets also block queries
for zones it doesn't maintain?  Basically doing the same thing as
setting allow recursion restricted to our-nets.  So if you have the
following options
allow-query { our-nets; };
allow-recursion { our-nets; };
And you set the allow-query option in each zone is there any reason to
also have the allow-recursion restricted to our-nets?  How could
someone not in our-net do a lookup on a zone not in your named.conf?

Thanks,
Nick


On 6/20/07, Niall O'Reilly <Niall.oReilly@ucd.ie> wrote:
>
> On 20 Jun 2007, at 17:33, Nick wrote:
> 
>
>         You hardly seem confused at all!  8-)
>
>         You may be overlooking referral responses.  A query for DNS data
>         contained in a zone not carried on your box and from an address
>         for which you have chosen to accept requests but to deny recursion
>         will result in a referral to "name servers which have zones which
>         are closer ancestors to the name [requested] than the server &
#91;your
>         box] sending the reply" [RFC1034, p.23].
>
>
>         Best regards,
>
>         Niall O'Reilly
>         university college Dublin IT Services
>
>         PGP key ID: AE995ED9 (see www.pgp.net)
>         Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9
>
>
>
>
>

[ Post a follow-up to this message ]

Kal Feher wrote:
> On 21/6/07 1:14 PM, "Clenna Lumina" <savagebeaste@yahoo.com> wrote:
> 
> No, I'll elaborate below from the 9.4 ARM:
>
> "allow-recursion
>
> Note that disallowing recursive queries for a host does not prevent
> the host from retrieving data that is already in the server's cache."
>
> and
>
> "recursion
>
>     Note that setting recursion no does not prevent clients from
> getting data from the server's cache; it only prevents new data from
> being cached as an effect of client queries. Caching may still occur
> as an effect the server's internal operation, such as NOTIFY address
> lookups."
>
> So we now use:
>
> "allow-query-cache
>
>    Specifies which hosts are allowed to get answers from the cache.
> The default is the builtin acls localnets and localhost. "
>

Sorry, I should been more clear. Using "recursion no;" in the scope of a
"view" seems to prevent _any_ resursive queries.

*   *   *

I even did a test using my bind 9.3.4 server that masters some zones.

From a remote ssh connection, I queried my server:

1) Queried one of the zones's it's authoritative for. Ok, that works.

2) Queried yahoo.com, got back a list of root servers (dig), nothing
more.

3a) on a local console, queried yahoo.com against the same bind server,
got 2 IPs for yahoo.com, 7 NS's (2 of which return A records in the
ADDITIONAL field.)

3b) sent the same query again from the remote console for yahoo.com, got
a list of root servers fro mdig agian, nothign changed.

And yes that name server (Bind 9.3.4) uses views, only allowing the
internal view to issue recursive queries (recursion yes;) while the
external only allows quering of zones the server is authoritative for
(recursion no;)

*   *   *

Works like a charm, nothing is taken from cache, so can you please
clarify how one would be able to get something out of my cache (like
google.com, etc) ?

--
CL

[ Post a follow-up to this message ]

The allow-query behaviour changed with 9.4
Allow-query-cache was added and is specific to the cache.
I note you tested on 9.3, I dont believe the statement allow-query-cache was
available on that release, hence your counter intuitive results.


On 22/6/07 10:09 AM, "Clenna Lumina" <savagebeaste@yahoo.com> wrote:

> Kal Feher wrote: 
>
> Sorry, I should been more clear. Using "recursion no;" in the scope of a
> "view" seems to prevent _any_ resursive queries.
>
>    *   *   *
>
> I even did a test using my bind 9.3.4 server that masters some zones.
>
> From a remote ssh connection, I queried my server:
>
> 1) Queried one of the zones's it's authoritative for. Ok, that works.
>
> 2) Queried yahoo.com, got back a list of root servers (dig), nothing
> more.
>
> 3a) on a local console, queried yahoo.com against the same bind server,
> got 2 IPs for yahoo.com, 7 NS's (2 of which return A records in the
> ADDITIONAL field.)
>
> 3b) sent the same query again from the remote console for yahoo.com, got
> a list of root servers fro mdig agian, nothign changed.
>
> And yes that name server (Bind 9.3.4) uses views, only allowing the
> internal view to issue recursive queries (recursion yes;) while the
> external only allows quering of zones the server is authoritative for
> (recursion no;)
>
>    *   *   *
>
> Works like a charm, nothing is taken from cache, so can you please
> clarify how one would be able to get something out of my cache (like
> google.com, etc) ?

--
Kal Feher

[ Post a follow-up to this message ]

Kal Feher wrote:
> The allow-query behaviour changed with 9.4
> Allow-query-cache was added and is specific to the cache.
> I note you tested on 9.3, I dont believe the statement
> allow-query-cache was available on that release, hence your counter
> intuitive results.

How are my results counter-intuitive? They were exactly as expected and
with one line of code (per view.)

You really avoided my question too. My examples (below, quoted)
demonstrate that the "recursion: no;" does stop cached queries as well,
so this seems for cleaner that having allow-query and allow-query-cache
at the same time.

And before you say it, yes, "recursion: " is different as it doesn't use
ACLs, unless you count "match-clients: " (ie, in a "view"), so it can be
used in virtually the same way as allow-query[-cache] with out having to
use two statements.

I just want to know what is so wrong with my aproach?

--
CL

> On 22/6/07 10:09 AM, "Clenna Lumina" <savagebeaste@yahoo.com> wrote:
> 
>
> --
> Kal Feher



--
CL

[ Post a follow-up to this message ]