BIND 8.x, security, and delegations

[Gregg TeHennepe]

Barry Margolin wrote:

> I have a guess.
> 
> The first query came from an address in your allow-query list.  So the
> server performed a recursive query, got the answer, added it to its cache,
> and returned it to the client.
>
> The second query came from an address not in the allow-query list.  If the
> answer hadn't already been in the cache, it would have returned the NS
> delegation records.  But since the answer was in the cache, it fell through
> to the code that tries to respond.  It then noticed that this was from an
> unauthorized address, so it rejected the query.

The first successful query was from 136.244.1.2, my ACL is defined as:

acl internal { 
        192.43.249/24; 
        192.233.40/24; 
        192.233.41/24; 
        192.233.42/24;
        192.233.43/24;
        199.94.152/24;
        199.94.153/24;
        199.94.154/24;
        199.94.155/24;
        199.94.156/24;
};

so I'm almost completely certain that the server correctly returned the referral
to the outside server on the first lookup. 

The trace shows no other queries for that hostname between the first successful
lookup and the subsequent rejection, so it appears it got into the cache during
the successful lookup and referral (maybe this is it?):

db_update(www.informatics.jax.org, 0x4a9b18, 0x4a9b18, 0, 031, 0x15dbc4)
db_update: adding 0x4a9b18

I've submitted a summary of this to bind-bugs at isc.org, issue #132.

Cheers - Gregg

-- 
Gregg TeHennepe  | Unix Systems Administrator  | The Jackson Laboratory
gat at jax.org      | http://aretha.jax.org/~gat  | Bar Harbor, Maine  USA