validating nxdomain for subdomains of data-less labels in auth-zone
mjt at tls.msk.ru
Fri Nov 11 13:26:35 UTC 2022
11.11.2022 14:31, George (Yorgos) Thessalonikefs via Unbound-users wrote:
> 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.
> Best regards,
> -- Yorgos
> On 08/11/2022 20:01, Michael Tokarev via Unbound-users wrote:
>> I'm not sure for the right wording used in $subject, but the issue is here,
>> let me describe it.
>> 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
>> This smells like a wrong behavior?
More information about the Unbound-users