in-addr.arpa insecure?

[Robert Moskowitz]

On 03/01/2013 08:57 AM, Tony Finch wrote:
> Robert Moskowitz <rgm at htt-consult.com> wrote:
>
>> I got tipped off about this from logwatch report. On my public DNS server had
>> the following:
>>
>> Feb 26 04:02:04 onlo named[19336]:   validating @0xb2929ee0: in-addr.arpa SOA:
>> got insecure response; parent indicates it should be secure
> Looks like something in your setup is dropping RRSIGs, and this is
> probably responsible for both your private htt. TLD validation problems
> and these in-addr.arpa validation problems. Do you all your servers have
> "dnssec-enable yes"? Do you have any non-BIND servers or middleboxes?

All my boxes are Centos 6.3 running RHEL bind 9.8.2.  I have 3. onlo is 
public facing and my main server.  rigel is my internal test box.  
klovia is my new mail server running as a cache server, currently 
forwarding to rigel, but will be switched to onlo when I swap it for the 
current klovia.  onlo and rigel are completely independent and on 
different subnets.  I mention the names as they are all findable via 
DNS; nothing private about that (though I am blocking chaos digs on all 
of them).

All in the global options have the lines:

     dnssec-enable yes;
     dnssec-lookaside auto;

Onlo and rigel have:

     dnssec-validation auto;

and klovia has:

     dnssec-validation yes;

hmmm.  I THOUGHT I had set onlo to also be 'dnssec-validation yes'. 
Probably did that in an earlier test version and when I did the final 
build, I forgot to change that line (auto is the RHEL default setting).  
And rigel started life as a clone of onlo.

So I will change dnssec-validation to yes, and see what happens.

Anything else I should look for?

Oh, no non-bind servers knowingly in the way.  I pay my ISP for a clear 
IP connection and 64 IPv4 addresses and a /48 IPv6 allocation.  My 
firewall is a Juniper SSG5 'branch' firewall with current firmware 
(there was an IPv6 bug in earlier releases that caused outbound routing 
problems) that is just passing port 53; no proxying enabled.