in-addr.arpa insecure?

[Robert Moskowitz]

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
Feb 27 04:02:04 onlo named[32262]: validating @0xb37e25e0:
in-addr.arpa SOA: got insecure response; parent indicates it should be
secure
Feb 27 23:35:37 onlo named[32262]: validating @0xb444ebc0:
in-addr.arpa SOA: got insecure response; parent indicates it should be
secure
Feb 28 04:02:08 onlo named[32262]: validating @0xb444ebc0:
in-addr.arpa SOA: got insecure response; parent indicates it should be
secure
Feb 28 09:37:00 onlo named[32262]: validating @0xb37d9fb8:
in-addr.arpa SOA: got insecure response; parent indicates it should be
secure
Feb 28 18:32:38 onlo named[32262]: validating @0xb4e014e0:
in-addr.arpa SOA: got insecure response; parent indicates it should be
secure
Mar 1 04:02:03 onlo named[32262]: validating @0xb37eac08:
in-addr.arpa SOA: got insecure response; parent indicates it should be
secure

Is this right? Is there some server out there that I hit occationally
that does not have the 'right' in-addr.arpa zone information?

[Tony Finch]

Robert Moskowitz <r...@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?

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

[Robert Moskowitz]

On 03/01/2013 08:57 AM, Tony Finch wrote:
> Robert Moskowitz <r...@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.

[Robert Moskowitz]

On 03/01/2013 09:22 AM, Michael W. Lucas wrote:

> You might have been here, but I feel obliged to throw this out: reply
> size problem?
>
> https://www.dns-oarc.net/oarc/services/replysizetest

Well something is south. Running this on onlo:

dig +short rs.dns-oarc.net txt
;; Truncated, retrying in TCP mode.
rst.x4091.rs.dns-oarc.net.
rst.x4049.x4091.rs.dns-oarc.net.
rst.x4055.x4049.x4091.rs.dns-oarc.net.
"2607:f4b8:3:0:9254:5400:0:148 DNS reply size limit is at least 4091"
"2607:f4b8:3:0:9254:5400:0:148 sent EDNS buffer size 4096"
"Tested at 2013-03-01 14:34:28 UTC"

But running it from this notebook I get:

dig @onlo +short rs.dns-oarc.net txt
rst.x1002.rs.dns-oarc.net.
rst.x1994.x1002.rs.dns-oarc.net.
rst.x2495.x1994.x1002.rs.dns-oarc.net.
"2607:f4b8:3:0:9254:5400:0:148 sent EDNS buffer size 4096"
"Tested at 2013-03-01 14:37:18 UTC"
"2607:f4b8:3:0:9254:5400:0:148 DNS reply size limit is at least 2495"

So why when run from the DNS server it truncates, but when same server
processes the request from a client it does not? Or is it, and just not
telling the client?

[Robert Moskowitz]

On 03/01/2013 09:22 AM, Michael W. Lucas wrote:
> On Fri, Mar 01, 2013 at 09:19:42AM -0500, Robert Moskowitz wrote:
>> On 03/01/2013 08:57 AM, Tony Finch wrote:
>>> Robert Moskowitz <r...@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).

Oh, rigel and klovia are on the same subnet, so not going through any
firewall. Other than Centos'.

>>
>> 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.
>
> You might have been here, but I feel obliged to throw this out: reply
> size problem?
>
> https://www.dns-oarc.net/oarc/services/replysizetest
>

> ==ml
>

[Robert Moskowitz]

On 03/01/2013 09:19 AM, Robert Moskowitz wrote:
>
> On 03/01/2013 08:57 AM, Tony Finch wrote:
>> Robert Moskowitz <r...@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.

No change in any behaviour wrt rrsig changing this to yes. Stopping
iptables and ip6tables also no change. rigel and klovia on same subnet,
so no firewall (Juniper ssg5) interfering.