Frequently Asked Questions

In the current system, the change of status in lifecycle of Domain will not take place in one set time but on a continuous basis, with changes being linked to the exact time of registration of that Domain.

The Registry system time and all operations related are in UTC.

Users (contacts) are managed in a new system with a different model than the old ones. While in the old system user data was verified and managed by SK-NIC, under the new rules this is the responsibility of the Registrar. The general sharing of user contact details is not permitted, in particular, given the new requirements of European data protection law (known as GDPR), each Registrar must manage its own set of contacts.

It is recommended that the Registrar maintains only one contact per subject / person – so changing the data of this entity will not require changing the data on all of its Domains.

However, it will not be possible to associate the Users (contacts) of other Registrars. Such a case occurs only when the authorized Domain Registrar changes – if the new Registrar wants to modify the contact details, they must replace them with their own. In order to compare the original Domain name data, the AuthInfo code can be used when the Domain Registrar is changed.

The change of the authorized contact information Registrar is not possible.

An authinfo Domain code is:

  • A security element of the Domain.
  • Is only visible to the current Domain Registrar, and it is provided to the holder.
  • Is necessary in order to change the Domain Registrar.

When registering each Domain, the Registrar can determine whether the AuthInfo code for the Domain will be automatically generated or manually enter it.

The code can be used by a Domain Registrant or New registrar, it is important to ensure that this code is maintained using the highest possible level of security.


Requirements for authinfo codes:

• Minimum number of characters: 16

• Maximum number of characters: 48

• Must be a combination of: Upper Case Letters, Lower Case Letters, Numbers & Special Characters.

• Special Chars allowed: ¬!”£$%^&*()_+=-[]{}:@~#’;?><,./

Base: at least: 1 upper, 1 lowercase, 1 number, 1 special


After changing the Registrar, the AuthInfo code is automatically pre-generated for the new system for security reasons. The Registrar may at any time change the AuthInfo code through the Registry Console in the Domain details.

When registering a User in the web interface, the system offers the possibility of automatically generating an ID, but the Registrar may change it, subject to the following conditions:

  1. Allowed ID length is at least 3 and maximum 16 characters,
  2. Characters in upper case are alphabetical alphanumeric without diacritics, digits 0 to 9, and “- /. /:” (Dash, dot, and two-digit).
  3. The identifier must not begin with the KEY prefix: or NS :.

FOR EXAMPLE , ID can be in the example Id27: zp8.4-corPX or MojeIDvSk-nic / 01

When using EPP, the Registrar always creates its own ID.

An authInfo code is a security element for the Domain. It is used to allow the secure change of Domain Registrar for the Domain. This code is automatically renamed to the new system after the Registrar is changed.

Note: when changing a Domain Registrant, by modifying the Domain data in the system, the authInfo code will not change. For security reasons the Registrar must manually change this code.

For correct functioning of EPP in the production environment it is necessary for the Registrar to whitelist their IP addresses in the Registrar Console: Settings – Access List.


The production EPP server access is established through TCP interface (secured with SSL), on port 700.

The access password can be found in the Registrar Console in Settings – Passwords

– it is recommended to change it in the beginning, and then change it periodically.

The test (OT&E) EPP server access is established through TCP interface (secured with SSL), on port 700.

The access data can be found in the Registrar Console in SettingsTest Accounts

– IDs and passwords of the test (OT&E) accounts are generated by the system

The extension on DNSSEC is being supported, following RFC 5910 and RFC 4034.

This extension adds additional elements to the EPP Domain name mapping.


Delegation Signer (DS) information is published by a DNS server to indicate that a child zone is digitally signed and that the parent zone recognizes the indicated key as a valid zone key for the child zone.

A DS resource record (RR) contains four fields: a key tag field, a key algorithm number octet, an octet identifying a digest algorithm, and a digest field.

Public key information provided by a client maps to the DNSKEY RR presentation field formats described in RFC 4034 section 2.2.

A DNSKEY RR contains four fields: flags, a protocol octet, an algorithm number octet, and a public key.

Maximum signature lifetime (maxSigLife) is an OPTIONAL child preference for the number of seconds after signature generation when the parent’s signature on the DS information provided by the child will expire. The maxSigLife value applies to the RRSIG resource record (RR) over the DS RRset.

SK-NIC’s server supports DS Data Interface.


For more information, see the EPP documentation in the Registrar Console – Support – Documentation.

The CDS scanning service works as an automatic DNSSEC activation based on Domain name servers’ data without a need for a Registrar to enter the data to the Domain Registry.

Therefore, only the setting (creation of a CDS record) on the web hosting resp. on DNS provider side is sufficient.

More detailed technical information can be found in the documentation on the SK-NIC website or in the Registrar Console: Support – Documentation.