Strange log messages

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange log messages

Lars Kollstedt
Hi,

what do the following messages in loose combination mean?:

Apr 22 09:23:01 resolver1 named[1201]:   validating ip6.arpa/SOA: got insecure
response; parent indicates it should be secure
[...]
Apr 22 09:32:23 resolver1 named[1201]:   validating in-addr.arpa/SOA: got
insecure response; parent indicates it should be secure
[...]
Apr 22 09:36:08 resolver1 named[1201]:   validating ./SOA: got insecure
response; parent indicates it should be secure


Theses are the only messages where I get "got insecure response; parent
indicates it should be secure". DNSSEC currently seems to work properly, but
there was a bit strange behavior with `dig +tries=6 +tcp +sigchase +trusted-
key=/usr/share/dns/root.key SOA <Reverse-Zone>`, yesterday night that hint me
to this strange message.

I'm seeing this on all our resolvers and for a longer time already. The BIND
version I am running is currently 1:9.11.3+dfsg-1ubuntu1.11.

Anyone else seeing this messages, too? ;-)

Kind regards
        Lars

--
Lars Kollstedt

Telefon: +49 6151 16-71027
E-Mail:  [hidden email]

man-da.de GmbH
Dolivostraße 11
64293 Darmstadt

Sitz der man-da.de GmbH: Darmstadt
Amtsgericht Darmstadt, HRB 9484
Geschäftsführer: Andreas Ebert


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange log messages

Tony Finch
Lars Kollstedt <[hidden email]> wrote:
>
> what do the following messages in loose combination mean?:
>
> Apr 22 09:23:01 resolver1 named[1201]:   validating ip6.arpa/SOA: got insecure
> response; parent indicates it should be secure

This means there is a DS record for ip6.arpa in the .arpa zone, but there
were no RRSIG records in the response to the ip6.arpa SOA query.

> I'm seeing this on all our resolvers and for a longer time already. The BIND
> version I am running is currently 1:9.11.3+dfsg-1ubuntu1.11.

This might be an instance of a bug that Mark mentioned last week:
https://lists.isc.org/mailman/htdig/bind-users/2020-April/102982.html

Older versions of BIND can fall back to non-DNSSEC queries for DNSSEC
zones. This can be more common if there is network disruption (I don't
know if the CenturyLink fibre cut issues have been resolved yet...)

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
German Bight, Humber: East or northeast 4 or 5, occasionally 6 at first.
Moderate. Fair. Good.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange log messages

Lars Kollstedt
Hi Tony, hi List,

on Mittwoch, 22. April 2020 12:27:27 CEST Tony Finch wrote:
> Older versions of BIND can fall back to non-DNSSEC queries for DNSSEC
> zones. This can be more common if there is network disruption (I don't
> know if the CenturyLink fibre cut issues have been resolved yet...)
One of the arpa-Nameservers 192.5.5.241, 2001:500:2::c which is the C-Root-
Server is shown to be not responsive for queries over UDP by DNSviz for a long
time. I haven't found out which flags to set to reproduce this, yet.

e.g.
https://dnsviz.net/d/1.4.0.0.8.b.1.4.1.0.0.2.ip6.arpa/dnssec/

but
dig DNSKEY arpa +tries=1 +dnssec +notcp @2001:500:2::c
simply works for me, and all others I tried, too.

Today there are also similar issues shown up with 193.0.9.2 and 2001:67c:e0::2
for ip6.arpa and 193.0.9.5 for 82.in-addr.arpa, I also can't reproduce them.

So we're possibly not needing link saturation to trigger this. ;-)



But when I understand this bug correctly, the issue is that bind9 is trying
some combinations that simply won't work when trying DNS Protocol legacy in
combination with DNSSEC. This causes unnecessary traffic and log messages but
there are no invalid results cached due to this.
The only case this can turn things worst is in combination with rate limiting
or link saturation.

The only thing that IMHO does'nt really fit into this is, how could the same
message occur e.g. on 09:29:49, 09:29:56, 09:30:18, 09:34:02 and 09:35:39 when
the TTL is 3600, refresh is 1800 and retry 900. From my understanding, the
SOA-RR and its RRSIG should be cached once a successful combination was found,
and there should be no further queries like this for at least 1800 seconds.

Or are there DNS extensions causing this RR to be cached multiple times? I
would expect such for www.google.de IN A or AAAA but not for in-addr.arpa IN
SOA. ;-)

I don't experience any delays when doing my troubleshooting queries, and I'm
seeing the TTL properly decreasing when querying the resolver.

Kind regards,
        Lars

--
Lars Kollstedt

Telefon: +49 6151 16-71027
E-Mail:  [hidden email]

man-da.de GmbH
Dolivostraße 11
64293 Darmstadt

Sitz der man-da.de GmbH: Darmstadt
Amtsgericht Darmstadt, HRB 9484
Geschäftsführer: Andreas Ebert


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange log messages

Tony Finch
Lars Kollstedt <[hidden email]> wrote:

> One of the arpa-Nameservers 192.5.5.241, 2001:500:2::c which is the C-Root-
> Server is shown to be not responsive for queries over UDP by DNSviz for a long
> time.

This is due to a stupid peering disagreement between a couple of very
stubborn tier 1 transit providers.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Malin, Hebrides, Bailey: Variable mainly northeasterly 2 to 4, occasionally 5
in east Malin and east Hebrides. Slight or moderate in east Malin and east
Hebrides, but elsewhere moderate throughout. Fair. Good, occasionally poor.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users