Report information
The Basics
Id:
45770
Status:
resolved
Priority:
Medium/Medium
Queue:

People
Owner:
Nobody in particular
Cc:
AdminCc:

BugTracker
Version Fixed:
9.12.0
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
(no value)
Priority:
P2 Normal
Severity:
S2 Normal
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
(no value)
Area:
bug

Dates
Created:Mon, 14 Aug 2017 12:19:51 -0400
Updated:Wed, 16 Aug 2017 00:19:31 -0400
Closed:Wed, 16 Aug 2017 00:19:31 -0400



This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

Subject: "no valid signature found" needs view & breadcrumbs
From: "Timothe Litt" <litt@acm.org>
Date: Mon, 14 Aug 2017 12:19:43 -0400
To: "bind9-bugs" <bind9-bugs@isc.org>

This morning I noticed that named was logging

  "dnssec: info:   validating <domain name>/SOA: no valid signature found"

The domain name appears in multiple views (4), where the internal and external view (pair)s use different keys.

Isolating the problem would be easier if the message included the view that is triggering this error.

It turned out that explicit queries failed with

  "lame-servers: info: RRSIG failed to verify resolving '<domain name>/SOA/IN'

Again, no view & no clue (expired? crypto? ??).  The zone is "auto-dnssec maintain", so there was no obvious user error.

  rndc sign <domain> in internal

on the master triggered a IXFR of 1 record (presumably an RRSIG for the SOA), after which the symptom disappeared (on both the master and slave servers).

All in all, there seemed to be a lack of breadcrumbs to track this down.  I can't say how long this was going on; the message is low severity & appears in logs going back to June - which is the event horizon.  The only SOA changes would have been due to UPDATE (of other records)/auto signing.

FWIW: This is a zone for which the server is authoritative (stub zone handles recursion to get validation); perhaps the severity should be higher in this case.   Or perhaps there should be a periodic integrity check on served zones that verifies proper signatures.  Or??

-- 
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

Message body not shown because it is not plain text.

ready for review.
Hi Timothe - I see Mark has updated this ticket via a comment... indicating he has addressed the issue you raised. 4681. [bug] Log messages from the validator now include the associated view unless the view is "_default/IN" or "_dnsclient/IN". [RT #45770]
Part of the issue here is that packet loss can't be treated as packet loss because there are nameservers that don't reliably respond to EDNS queries (old Microsoft Windows servers fall into this category, still out there) and there are firewalls that drop EDNS queries (getting rare these days) or drop EDNS queries with EDNS options present (still plenty of these). To get answers out of these servers, named falls back to plain DNS queries. Unfortunately when we do this and the zone being looked up is signed we don't get DNSSEC records returned. The unsigned answers then fail validation. Requerying usually works. Add to this there are also firewalls that block ICMP packet to big messages so path MTU discovery fails and there are firewalls that block fragmented packets. We try to work out what the remote server supports but it takes a reasonable amount of traffic to do this.