Bind doesn't look up past its own Domains

[aklist_bind at enigmedia.com]

>>
>>// -------------------
>>// OPTIONS
>>// -------------------
>>
>>options {
>>        directory "/var/named";
>>        dump-file "/var/named/data/cache_dump.db";
>>        statistics-file "/var/named/data/named_stats.txt";
>>        query-source address * port 53;
>>        recursion no;
>>};
>>
>>Doesn't one want to have recursion set to NO to keep others from using 
>>your
>>DNS server for lookups or should the restrictions be set elsewhere for 
>>that.
>>In otherwords, I want the local network to use the nameservers for 
>>lookups,
>>but I don't want the outside to.  Restrict by IP?
>>
> You could do that, via "allow-recursion". That gives a "friendly"
> response to queries outside of your hosted zones, a referral to the
> closest information in the hierarchy that your server knows about.
> Trouble is, it may give out *too*much* information for some of the more
> security-minded types -- if the answer to the query is in your cache, it
> will be returned, since no recursion is necessary to fetch it. Allowing
> arbitrary Internet clients to get query answers from your cache could
> theoretically allow them to do forensics on what sites your clients are
> visiting, etc. so it may be undesirable to give access to that data.
> Also, answering from cache may attract some "mooches" who think they can
> use you as a pseudo-resolver (you're likely to have the answer to
> popular queries in your cache at all times).
>
> A more stark approach, to which Mark alluded indirectly, is to use a
> restrictive "allow-query" globally, with liberalized overrides for all
> of the zones you host. So if an external client queries outside of your
> hosted zones they get an unfriendly REFUSED response, instead of
> whatever cached data you might happen to have.
>
> A more sophisticated approach would involve having separate views for
> internal and external clients, with recursion turned off in the external
> view. In that case, queries outside of hosted zones would return an
> "upwards referral" to the root zone. Since this is hardly more useful to
> resolvers than a REFUSED response, the views approach might be overkill
> if all you're trying to do is restrict access. There are other
> architectural reasons why you might want to implement such a
> view-separation though...

I'd just like to double-check that I have my recursive options set 
correctly.

I have a public and private view, with the private view defined as an ACL 
"localsubnet" with my local subnet IPs in it.

In my options I don't have any recursion statements.

My internal view comes first, with the following setting:

view "internal" {
    match-clients {"localsubnet"; };
    recursion yes;
//zone info here
};

then the external view:

view "external" {
    match-clients {any;};
    recursion no;
//zone data here
};

Is that OK, or do I also need an "allow-recursion" statement in my options?

TIA, Andrew