allow query / allow recursion confusion

[Clenna Lumina]

Kal Feher wrote:
> From the 9.3 ARM
> "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"
>
>
> specifically:
> To barry's email saying that allow-query-cache now did what
> allow-recursion was thought to do, you said "recursion no" did this.
> It does not, as clearly stated in the ARM excerpt above. Yes it seems
> cleaner, but no it doesn't work.

Doesn't work? My setup seems to disagree with you as I does my test 
which I posted. I set the "external" view to have "recursion: no" while 
setting the same to "yes" for the "internal".

Each view is properly ACL'ed inthe match-clients clause.

I can look up any domain fro mthe "internal" side, but from any terminal 
on the "external" side (read: anywhere else on the internet) I cannot 
look up any domains other then what my server is authoritative for. Even 
if I looks up, say "yahoo.com" on the "internal" side and immediately 
thereafter attempt the same lookup against my name server from an 
"external" terminal (I ssh'ed into a remote system), I cannot get 
anything other than a list of root servers. No "yahoo.com" records, 
cahced or otherwise.

Bottom line: cached responses are not available when "resursion: no" is 
used. After the first lookup on the "internal" side, an repeat queries 
are instant, so they are being cached.

> In 9.3 if you wanted this behaviour you could use allow-query with
> acls as many default bind configs will in fact do. But "recursion no"
> doesn't replicate this behaviour.

Apparently it does (see above.) I've proven it already.

> To my reading of the ARM (9.3 and 9.4) and experience with BIND it
> appears fairly clear cut.

Then the ARM (manual?) is incorrect, at least for 9.3.4, which is what 
I'm using.

> As to your experiment, perhaps you could include the full named.conf
> if you feel its genuinely possible to block the querying of the cache
> with "recursion no".

I already disclosed the realavent parts, but heres a more complete 
version:

   options {
      directory "/var/named/";
      pid-file "/var/run/named/named.pid";
   };

   [...]

   acl "lan" { 192.168.0.0/16; localhost; };

   [...]

   view "internal" {
      match-clients { "lan"; };
      recursion yes;

      [...list of zones...]
   };

   view "external" {
      match-clients { any; };
      recursion no;

      [...list of zones...]
   };



One last time. "recursion no;" doesn't seem to let eve ncached queries 
through. So I want to know whats wrong with using "recursion no/yes;" 
(maybe in conjunction with "match-clients { ... };") instead of 
"allow-query[-cache]" + "allow-recursion" ?

I'm just saying it works perfectly for me.


> On 22/6/07 1:38 PM, "Clenna Lumina" <savagebeaste at yahoo.com> wrote:
>
>> 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?
>
> --
> Kal Feher



-- 
CL