DNSSEC for .si: Technical Guide to Setup and DS Record Submission
9 min read
DNSSEC for .si: A Technical Guide to Setup and DS Submission
Yes, DNSSEC for .si is supported, and the chain of trust to the root zone is established. The first technical step is verifying that your child zone contains the correct DNSKEY and that a Zonemaster pre-delegation test confirms the records are correctly signed. Only then do you submit the DS record to Register.si.
In short:
Before submitting a DS record, all name servers need to publish the same DNSKEY, respond over both UDP and TCP, and return RRSIG signatures; Zonemaster must show no critical errors.
.si uses the ECDSA algorithm with the P-256 curve and SHA-256; rotate the ZSK roughly every 30 days, and the KSK once a year.
A DS record contains a key tag, algorithm, digest type, and digest; an incorrect character or an out-of-sync server clock can cause rejection or invalid signatures.
After activation, monitor RRSIG signature expiry, SERVFAIL errors, and whether the DNSKEY matches the registry; if you lose a key, temporarily removing the DS record stops validation.
Moxy-web — Manage your web solution securelyMoxy-web builds web solutions with a focus on security, and offers hosting, technical support, and maintenance.Check out Moxy-web's services
Table of Contents
What DNSSEC means for .si: status, the chain of trust, and relevant documents
Preparing your zone before submitting a DS record: Zonemaster, checkpoints, and common pitfalls
Practical examples and recommendations for DNS and DNSSEC setup for Slovenian clients
Perspective: why administrators in Slovenia shouldn't delay DNSSEC
What DNSSEC means for .si: status, the chain of trust, and relevant documents
The .si top-level zone has had an established chain of trust since 2011, when Arnes added DNSSEC validation to its recursive servers. This means signing domains under .si has long been part of standard infrastructure, and recursive servers in Slovenia often validate signatures automatically.
Register.si maintains a detailed DNSSEC Practice Statement, setting out the operational framework for the whole zone. Key points from this document:
keys are generated and stored in hardware security modules (HSMs) with appropriate certification,
the ZSK is rotated roughly every 30 days, and the KSK once a year,
currently valid keys use ECDSA Curve P-256 with SHA-256 (algorithm 13),
the zone uses NSEC3 to prevent record enumeration.
The broader framework .si sits within is also set by IANA's procedures for managing the root KSK, which describe key ceremonies and rollover practices at the top of the chain of trust. .si domain administrators don't deal with these procedures directly, but understanding this hierarchy explains why certain deadlines and algorithms are mandated the way they are.
Preparing your zone before submitting a DS record: Zonemaster, checkpoints, and common pitfalls
Before you submit a DS record anywhere, your zone needs to pass a pre-delegation test. Register.si uses a DNS verification tool for this, built on Zonemaster, which checks compliance with .si's requirements.
Process before submitting a DS record:
Check that your name servers respond to both UDP and TCP queries, since signed responses often exceed the size of a standard UDP packet.
Make sure the AA bit is set correctly and that your servers support EDNS0 with an adequate packet size.
Check that queries with the DO bit set return RRSIG records along with the requested data.
Compare the DNSKEY in your zone against the digest you intend to submit as the DS record, since they need to match exactly.
Run a Zonemaster test and check that the report contains no ERROR- or CRITICAL-level warnings.
The most common mistakes we see when preparing a zone are a missing DNSKEY on one of the secondary servers, a mismatched digest value from an incorrectly copied key, the wrong digest type selected, and out-of-sync system clocks between servers, which invalidates RRSIG signatures. Firewalls blocking UDP packets above a certain size are also a common cause of failed tests.
Pro tip: Run the Zonemaster test at least twice, a few hours apart, to rule out temporary sync issues between secondary servers.
Generating and managing keys (KSK and ZSK) for .si zones
The algorithm you choose affects response size, server load, and long-term maintenance. Three algorithms are relevant for .si zones:
RSA with SHA-256 (algorithm 8): the most widely used, but produces larger signatures and records,
ECDSA Curve P-256 with SHA-256 (algorithm 13): smaller signatures at the same security level, currently used in Register.si's current DPS,
Ed25519 (algorithm 15): a modern algorithm with efficient signing, but less widely supported in older software.
ZSK rollover for .si happens roughly every 30 days, and KSK rollover once a year, meaning automating key rotation isn't just recommended — it's practically essential for smooth operation.
Register.si's DPS describes using hardware security modules (HSMs) with FIPS 140-2 certification to generate and store keys, along with formal key-generation ceremonies and backup procedures. For their own infrastructure, administrators most commonly use OpenDNSSEC or BIND as their signing software. It makes sense to fully automate ZSK rollover, while KSK rollover, given its higher risk, is typically carried out manually, in a test environment before the production change.
How to build and submit a DS record for .si
The DS record you submit to Register.si needs to contain four precisely defined components:
Key tag: a numeric identifier for the KSK key, calculated from the DNSKEY record.
Algorithm: the algorithm number matching the KSK used (13, for instance, for ECDSA P-256 with SHA-256).
Digest type: the hashing method, typically SHA-256 for .si.
Digest: the actual hashed value of the public key, calculated from the DNSKEY.
The most common cause of a rejected submission is a mismatch between the DNSKEY published by your zone and the digest value you submit to Register.si. This happens when you change a key but forget to update the DS record, or when a single character gets mistyped while copying the digest.
Before submitting your DS record, verify:
That the DNSKEY the DS is derived from is actually published in the zone on every name server.
That the Zonemaster test completes successfully with no critical warnings.
That the clocks on all servers are synchronized, since this affects RRSIG signature validity.
Operational maintenance and troubleshooting after signing
The work doesn't end once the DS record is submitted, since a signed zone requires ongoing monitoring. Regularly rerunning Zonemaster tests, tracking RRSIG signature expiry dates, and automated alerts on SERVFAIL responses are the foundation of reliable operation.
Diagnostic steps we use when troubleshooting:
checking the response with
dig +dnssecto inspect RRSIG and DNSKEY records,comparing signature validity against the server's current time,
reviewing the signing software's logs (OpenDNSSEC or BIND) for rollover errors,
checking whether the DNSKEY and the DS record in the registry are still aligned after any key change.
If you lose a key, or hit a critical error threatening the domain's availability, the fastest fix is to temporarily remove the DS record from the .si registry, which halts validation until you've set up a new, correctly matched key.
Pro tip: Always add the next RRSIG signature's expiry date to your task calendar; don't rely solely on your signing software's automatic alert.
Practical examples and recommendations for DNS and DNSSEC setup for Slovenian clients
When preparing hosting for clients before signing a zone, we always check that the name servers support TCP connections and EDNS0 with a sufficient packet size, since this often causes a Zonemaster test failure if not sorted out in advance.
For key management, we suggest active support when clients don't have their own IT team to monitor rollovers, or when it's the first DNSSEC implementation on their domain. In these cases, we help correctly submit the DS record through the registrar and synchronize server time settings.
For clients preparing to take over a service, we recommend setting up DNS management access in advance, verifying clock synchronization across all servers, and running at least one test cycle before the actual production submission.
Perspective: why administrators in Slovenia shouldn't delay DNSSEC
The biggest mistake with DNSSEC isn't technical — it's organizational: businesses treat it as a one-time project rather than an ongoing operational obligation. Testing before submission and an agreed-upon rollover process with the registrar often matter more than which algorithm you pick.
— Ziga
How we can help you implement DNSSEC
We set up DNS configuration, hosting, and domain registration so the zone is ready for signing without later server fixes. We also help generate keys and correctly submit the DS record to Register.si when a client doesn't have an in-house team for it.
For businesses also managing broader digital infrastructure, it's worth checking out this checklist for digitalizing accounting too, since security and administrative steps in digitalization often overlap.
If you need help with DNS settings, hosting, or submitting DNSSEC for your .si domain, check out our service offering and arrange a review of your zone.
Frequently asked questions
Is DNSSEC mandatory for .si domains?
No, DNSSEC isn't mandatory for .si, but it's supported and recommended for domains where DNS response reliability is critical. The chain of trust to .si has been established since 2011, making it easy to enable at any time.
What is Zonemaster, and why do I need it before submitting a DS record?
Zonemaster is a tool for checking delegation and DNSSEC settings, which Register.si uses for pre-delegation tests. If the report returns an ERROR- or CRITICAL-level warning, Register.si won't delegate the domain until the issues are fixed.
Which algorithm should I use for the KSK and ZSK on .si?
Register.si's current DPS uses ECDSA Curve P-256 with SHA-256 (algorithm 13), which offers smaller signatures at the same security level as older RSA. Before choosing it, verify that your signing software supports this algorithm.
What do I do if Register.si rejects my DS record submission?
The most common cause is a mismatch between the published DNSKEY and the digest value in the DS record, so check that the two match first. Then rerun the Zonemaster test, and only resubmit once the report comes back successful.
How often do I need to rotate keys after setting up DNSSEC?
Per Register.si's recommendations, the ZSK is rotated roughly every 30 days, and the KSK once a year. It makes sense to automate ZSK rollover, while KSK rollover, given the risk involved, is typically done manually and under close supervision.