Process of authentication of information, received through DNS protocol, is based on a “chain of trust” which requires particular levels of domain zones to be signed properly in accordance with a hierarchical structure of DNS. It denotes that in order to secure a domain name it is necessary to sign a zone of that domain and enter a specific cryptographic digest from the public part of a zone signing key (Delegation Signer record) to a parent domain zone in the DNS hierarchy where a domain name, subject to be secured, has been registered. Here, in turn, the digest should be signed with a private key and its digest passed on correspondingly to a parent zone. The chain is built up to the Root zone (highest level in DNS hierarchy) where a key, denoted as “Trust Anchor” and commonly considered as trusted, is located.

A registrant of a .pl domain name may secure their name by signing it with a DNSSEC key and placing in a parent zone of a cryptographic digest as a DS record from the public part of a signing key.

If you are a registrant of a .gov.pl domain name and want to secure the name with DNSSEC protocol, please file a proper application through a request for a change of delegation.

Registrants of other .pl domain names should refer their questions, on securing their names with DNSSEC, directly to their registrars.

End user, willing to benefit from DNSSEC, may use free solutions for web browsers (plugins) which use DNSSEC extension and warn the user about potential threats.

Change of delegation of a .pl domain name, secured with DNSSEC, is reported to NASK in the same manner as the change of delegation of an unsecured .pl domain name.

If you are a registrant of a .gov.pl domain name secured with DNSSEC and want to change delegation, please file a proper application through a request for a change of delegation.

Registrants of other .pl domain names should refer their questions, on changing delegation of their names, directly to their registrars.

While changing delegation of a domain name, secured with DNSSEC, you should pay particular attention so as the chain of trust is not broken accidently.

Improper configuration of a zone during change of delegation of a .pl domain name, secured with DNSSEC, may cause the chain of trust broken which result in zone validation errors. As a consequence of those errors, DNS queries will not be responded with IP address.

Please note that:

• change of domain delegation cannot impede the process of setting up a chain of trust;
• errors in validation are more dangerous than the lack of validation option itself, if there is a chance to select the lesser of two evils, it is preferred to use an unsecured zone, however this action should also be limited to minimum;
• critical material in a form of parts of private zone signing keys, is never exchanged between technical administrators;
• unknown RRSIG records should not be entered in the administered zone;
• interaction between registry, registrar, technical administrator and registrant should be limited to minimum;
• if the interaction cannot be avoided, a new technical administrator should bear the weight of conducting the delegation change process, releasing a current technical administrator who loses the control over .pl domain name service;
• apart from DNSSEC mechanisms, the process of changing the delegation should be conducted in the same manner as in the case of a .pl domain name not secured with DNSSEC.

The following assumptions should be made:

• lack of direct communication between a current and new technical administrator of a domain name;
• foreign DNSKEY records are available to be included in a zone and signed in order to provide uninterrupted validation of the chain of trust along DS/KSK/ZSK records, both at the current and new technical administrator;
• both the current and new technical administrator support the same encryption algorithm;
• in the zone there is division between ZSK and KSK.

Change phases (including three changes in the .pl registry):

1. At the moment of commencing the change, DS record in a parent zone indicates a Key Signing Key (KSK) belonging to the zone of a technical administrator from whom a .pl domain name is being moved.
2. A new technical administrator through DNS mechanisms retrieves a ZSK record from an acquired zone (from a current technical administrator), verifies with DNSSEC mechanisms whether the record is correct and adds it to DNSKEY records, located on their servers, and signs a new set of DNSKEY records with own Key Signing Keys and Zone Signing Keys. At this phase a new infrastructure is not ready to accept DNS queries yet, but thanks to the operation, described above, the validation of old RRSIG records with new KSK and ZSK has become possible.
3. The current technical administrator receives from a registrant a new DNSKEY record containing ZSK and allocates it in their zone, then, the administrator signs a new set of records with their KSK and ZSK.
   At this phase the validation of new RRSIG records with old KSK and ZSK is possible.
4. A registrar, as requested by a registrant, changes the delegation of a .pl domain name by adding a new DS record indicating a new KSK (first change in the .pl registry).
   At that phase, after the lapse of time, specified by TTL of the old ZSK, resolvers will not hold in their memory any set of DNSKEY records or they will hold a set of DNSKEY records signed with an old KSK and containing a new Zone Signing Key.
5. If the memory of resolvers holds a set of DS records containing a digest to a new KSK (i.e. old set of DS records expired) it is permitted to change the delegation of a domain name and to specify servers of a new technical administrator (second change in the .pl registry).
   After this step, a parent zone will contain a delegation to new servers and two DS records indicating old and new KSK. Due to application of two DS records verification of both sets of DNSKEY is available.
6. If all sets of DNSKEY records containing an old KSK have expired (a DNS resolver of a previous technical administrator should not respond to DNS queries), a registrar, as requested by a registrant, changes the delegation of a domain name deleting the old DS record (third change in the .pl registry).
   Minimal time to wait before taking the final step is the total number of time periods:
   • TTL (Time to Live) of a set of NS records located in a parent zone,
   • TTL of a set of NS records responded by an authoritative server,
   • TTL of a set of DNSKEY records of the old zone.

If a registrant has no contact with a current technical administrator of a domain name or the administrator refuses to place a new DNSKEY record in the zone, before changing the delegation it is necessary to unsign the zone by deleting a DS record from a parent zone, change delegation, change keys for new and place again the DS record in a parent zone.

Domain name transfer procedure is the same as in case of an unsecured domain name. Questions on the procedure should be referred directly to the registrar where you want to transfer your domain name. Before commencing the procedure, please make sure that the registrar, you have chosen, is able to pass DS records to NASK.

When compromising (revealing) a key is suspected, make sure that the infrastructure is safe and then effect the procedure of exchanging keys with an additional option of revoking old (compromised) data by setting the REVOKE bit in DNSKEY records.

DNSSEC Policy and Practice StatementDNSSEC Policy and Practice Statement – this document specifies the procedures and rules applied in the registry of .pl domain names secured with DNSSEC. The document refers to the zones administered by NASK.
A complete list of zones, administered by NASK, is available at http://www.dns.pl.

NASK accepts DS records with the following values of algorithm and digest function type:

• key algorithm type

• digest function type