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 <[email protected]>
Sent: Monday, June 30, 2025 2:49 PM
To: Barshani Jalaludeen <[email protected]>
Cc: [email protected]
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
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
