Hello!
I'm not sure for the right wording used in $subject, but the issue is here,
let me describe it.
auth-zone:
name: "dom"
primary: <primary-ip>
zonefile: "dom.cached"
for-downstream: no
With this config, and with "dom" containing the following
3 records (+ all the right DNSSEC ones):
a.x A 127.0.0.1
y A 127.0.0.1
b.y A 127.0.0.1
query for foo.y.dom (non-existing) return NXDOMAIN, but
query for foo.x.dom (also non-existing) return TEMPFAIL,
with the following in the log:
unbound: [73699:0] debug: NameError response has failed to prove: covering wildcard does not exist
unbound: [73699:0] debug: NODATA response failed to prove NODATA status with NSEC/NSEC3
unbound: [73699:0] info: validate(nxdomain): sec_status_bogus
(with many other debugging info omitted).
The difference between foo.x.dom and foo.y.dom is that the
intermediate label in first case (x.dom) does not have its
own records, while in the second case (y.dom) does have an
A record. So for any subdomain of a label which does not have
its own records but which exists, unbound fails to validate
NXDOMAIN.
This smells like a wrong behavior?
Thanks!
/mjt
Hi Michael,
Without having anything specific to look at I would guess that Unbound is doing the right thing and that the signing part is not properly creating NSEC/NSEC3 for the Empty Non Terminal 'x.dom.'.
Best regards,
-- Yorgos
Hi Michael,
Without having anything specific to look at I would guess that Unbound is doing the right thing and that the signing part is not properly creating NSEC/NSEC3 for the Empty Non Terminal 'x.dom.'.
Hello George! Thank you for the reply.
Can you say how to debug this further?
The original zone file is signed using ldns tools, namely,
ldns-signzone, as a single file with all the records in there.
It is served by NSD and Unbound is configured to fetch it
from there. So it is basically a single-shop, all the familiar
tools, some of which are failing.
The zone in question is tls.msk.ru, the empty-label subdomain
is pz.tls.msk.ru, - I've added a TXT record for this name in
order to work around this very issue. Any non-existing
foo.pz.tls.msk.ru is failing in unbound.
Thank you!
/mjt
Now I spot that this is auth-zone.
Which version of Unbound is that?
I would first try with stub-zone instead and point to the NSD instance you mentioned.
Best regards,
-- Yorgos
11.11.2022 16:54, George (Yorgos) Thessalonikefs wrote:
Now I spot that this is auth-zone.
Yes it is auth-zone. It is set up this way because it is a remote office with
somewhat flaky connectivity and I thought about always having whole thing locally
instead of relying for the upstream during all the runtime.
Which version of Unbound is that?
It is 1.16.3 currently. I thought about giving 1.17 a try, - upgraded to 1.17.0,
with exactly the same effect. (It is Debian package of Unbound, - I'm trying to
keep it current in Debian).
I would first try with stub-zone instead and point to the NSD instance you mentioned.
The stub-zone works, it worked for many years (with not a best reliability, see
above). I just tested it again - switching from auth-zone to stub-zone with the
same stub-address works just fine.
It is only the auth-zone which dosn't work - I removed the temporary TXT record and
it started failing again.
Thanks!
/mjt
This does sound like a bug for auth-zone then.
I don't have time to replicate atm but could you open an issue for it?
Also, is this NSEC or NSEC3?
Best regards,
-- Yorgos