: expected covering NSEC3, got an exact match
on both our main authoritative-only (recursion no) nameservers. Our own
zones don't use NSEC3, but we do officially slave two that do (srcf.net
and srcf.ucam.org) so I have been assuming that they are responsible in
some way. But we didn't chang
igning when the
corresponding record had been removed (Bug #20478). This was fixed in
9.7.0 or thereabout.
> Since 2011-09-02 we have been seeing messages like this
> Sep 22 16:38:52 authdns1.csx.cam.ac.uk named[646]: dnssec: warning:
> client 149.20.58.131#52557: expected covering NSEC
There was some correspondence last year about this warning message, but
this seems to be caused by something new.
Since 2011-09-02 we have been seeing messages like this
Sep 22 16:38:52 authdns1.csx.cam.ac.uk named[646]: dnssec: warning:
client 149.20.58.131#52557: expected covering NSEC3, got
Thanks, Marc.
Mark Andrews wrote:
> It's cosmetic. The final NSEC3 record proves the non-existance
> of the data or wildcard. With a nodata response we should be
> expecting the record. The following has been compiled but otherwise
> has not been tested.
It works here, and seems to have the ex
It's cosmetic. The final NSEC3 record proves the non-existance
of the data or wildcard. With a nodata response we should be
expecting the record. The following has been compiled but otherwise
has not been tested.
Mark
Index: bin/named/query.c
==
Kalman Feher wrote:
> Ok now I see it.
> The response appears ok, but the log entry is odd. I see the same on my test
> box (9.7.1 not patched to P1 yet).
I saw this on earlier 9.7 as well.
> A brief thread on this occurred earlier
> in the year (archived here):
> http://newsgroups.derkeiler.com
Ok now I see it.
The response appears ok, but the log entry is odd. I see the same on my test
box (9.7.1 not patched to P1 yet). A brief thread on this occurred earlier
in the year (archived here):
http://newsgroups.derkeiler.com/Archive/Comp/comp.protocols.dns.bind/2010-03
/msg00282.html
On 13
Kalman Feher wrote:
> It looks like normal NSEC to me, unless you are referring to an isolated
> copy of the domain not accessible to the public:
Yes, indeed, sorry about that. I should keep my playgrounds tidier. The
actual zone is located on nssec.restena.lu, and is publicly queriable
(even wit
ME is matched
> by the wildcard, but the QTYPE is not, named logs a warning: "expected
> covering NSEC3, got an exact match".
>
> This behaviour exists only if a wildcard is present in the zone. The
> zone doesn't contain any stale or unnecessary NSEC3 records.
>
ected
covering NSEC3, got an exact match".
This behaviour exists only if a wildcard is present in the zone. The
zone doesn't contain any stale or unnecessary NSEC3 records.
Is there an explanation for the warning? Apart from complaining, bind
seems to do everything correctly. (Bind 9.7.1 P1
On Sun, 28 Mar 2010, Nate Itkin wrote:
28-Mar-2010 21:02:27.467 dnssec: warning: client 200.160.7.134#6363: view
external: expected covering NSEC3, got an exact match
The error suggests the following happened. The client asked for something
that did not exist. The server then hashes the
external: expected covering NSEC3, got an exact match
Thank you,
Nate Itkin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
12 matches
Mail list logo
