From ods-dog at hole.fi  Tue Jul  8 15:03:38 2025
From: ods-dog at hole.fi (Mikko Rantanen)
Date: Tue, 8 Jul 2025 18:03:38 +0300 (EEST)
Subject: [Opendnssec-user] opendnssec / ldns-verify-zone - A has
 signature(s), but is occluded (or glue)
In-Reply-To: <DBBPR01MB10507F989A64ECED21B1AEFA4FD46A@DBBPR01MB10507.eurprd01.prod.exchangelabs.com>
References: <DBBPR01MB1050787AE5E6D39E2B1BECB9DFD46A@DBBPR01MB10507.eurprd01.prod.exchangelabs.com>
 <20250630.134925.1061436641722647116.he@uninett.no>
 <DBBPR01MB10507F989A64ECED21B1AEFA4FD46A@DBBPR01MB10507.eurprd01.prod.exchangelabs.com>
Message-ID: <alpine.DEB.2.21.2507081653050.9967@rat.hole.fi>

Hello all,

(I'm Barshani's colleague)

while I didn't yet dig into why this happens, it looks to me (based on the 
presented zone files and resulting visible signatures) that the failing 
zone does not have NSEC3 records that exist in non-failing zone file 
(those between example.com., ns1.site1.example.com., 
ns2.site1.example.com. and site2.example.com.).

If the RR
1ale25q63qf27j2lrhoqm9um0a3u3e6r.example.com.   3600    IN      NSEC3   1 
1 5 4d91322a387fea14  6khjs8s1km7q7o0kiuo75681umgi1vne NS SOA RRSIG DNSKEY 
NSEC3PARAM
covers everything under example.com and zone is missing the 
6khjs8s1km7q7o0kiuo75681umgi1vne.example.com. NSEC3 for A,RRSIG,
wouldn't it mean that ns1.site1.example.com. A RRSIG records are 
guaranteed to not exist? I might be wrong here, though.

While I didn't dig into the code to try and figure out if it would be 
related to something like <OptOut/>-stanza, we had to try the fix earlier 
today on a working (non-broken) zone. We then noticed that when the 
'ods-signer clear <zone>' is run, it will also schedule zone resign 
despite documentation (and examples in the internet) lets us understand 
that would not happen. This is in file 
opendnssec-2.1.14\signer\src\daemon\signercommands.c ,
function 'static int cmdhandler_handle_cmd_clear(cmdhandler_ctx_type* context, char *cmd)' 
which runs
'schedule_scheduletask(engine->taskq, TASK_FORCESIGNCONF, zone->name, zone, &zone->zone_lock, schedule_IMMEDIATELY);' .
It is task 'TASK_FORCESIGNCONF' but.. well, it triggers immediate 
zone re-signing when we run it.

Based on the solution, my guess would be that there's something that makes 
ods pick the A RRSIG from the so-called backup-files under 
/var/opendnssec/tmp (whether rightly or wrongly, as they are time-wise 
valid, and with same timestamps so they probably do come from the 
backups). Why the NSEC3 is not generated, I don't know, but the behaviour 
of 'ods-signer clear <zone>' was kinda unexpected because our signing 
uses NotifyCommand to run several checks to ensure zone validity (loading 
into bind, running ldns-verify-zone, distributing validated zones, sending 
e-mail about process results and so on) if signed zone passes our tests.

I think summa summarum is something like:

   - deleting and then reintroducing a (sub)domain with glues and
     A RRSIGs will restore the A RRSIGs from .backup files but
     does not regenerate NSEC3
   - 'ods-signer clear <zone>' does always 'schedule_IMMEDIATELY'
     a 'TASK_FORCESIGNCONF' task when zone exists
   - I guess that the scheduling of a TASK_FORCESIGNCONF task somehow
     triggers immediate re-signing as well which feels like a bug.
   - The comment just above schedule_scheduletask is interesting


Best regards,

-- 
Mikko Rantanen


On Mon, 30 Jun 2025, Barshani Jalaludeen via Opendnssec-user wrote:

> Hi Havard,
>
> Thanks for your quick support.
>
> We did the following, without update any record in unsigned zone file after test case3 #  Occluded (glue) issue.
>
> cd /var/opendnssec/unsigned/
> r0ts-dns-ids01:/var/opendnssec/unsigned# sudo -u ods ods-signer clear example.com
> Internal zone information about example.com cleared
>
> sudo -u ods ods-signer sign example.com
> cd /var/opendnssec/signed
> cat example.com
> r0ts-dns-ids01:/var/opendnssec/signed# ldns-verify-zone /var/opendnssec/signed/example.com
> Zone is verified and complete
>
> It seems signing of example.com working fine.
>
> Note:- Is this means bug in opendnssec to handle such scenario?  Any suggestion please.
>
> Thanks
>
>
>
>
> -----Original Message-----
> From: Havard Eidnes <he at uninett.no>
> Sent: Monday, June 30, 2025 2:49 PM
> To: Barshani Jalaludeen <barshani.jalaludeen at oivan.com>
> Cc: opendnssec-user at lists.opendnssec.org
> Subject: Re: [Opendnssec-user] opendnssec / ldns-verify-zone - A has signature(s), but is occluded (or glue)
>
> CAUTION: This email originated from outside Oivan. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>> We are getting the error while verify the opendnssec signed zone file
>> - " A has signature(s), but is occluded (or glue)"
>
> Yep, I see what's going on.
>
>> Following is the test cases done on the opendnssec server. I am not
>> sure, it is a bug or do we need to follow some procedure to avoid this
>> issue. Please suggest.
>
> In general, the remedy for this is to remove non-glue non-authoritative data from your un-signed zone.
>
> However...  It seems that the operations you are performing, in particular going from #2 where the site1.example.com delegation has been removed to re-introducing site1.example.com as a delegated zone in step #3 is changing the "glueness" of the A records for
>
> ns1.site1.example.com.
> ns2.site1.example.com.
>
> and it's entirely possible that OpenDNSSEC doesn't handle that correctly, and instead retains the signatures for those A records which were (correctly) computed in step #2.
>
> A possible workaround is to remove both the delegation of site1.example.com and the glue records, have OpenDNSSEC sign that zone, and then re-introduce both at the same time and have OpenDNSSEC do a new signing operation.
>
> Best regards,
>
> - H?vard
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
>