The DNS protocol was designed is such way, that it provided a quick and easy way for the Internet user to be
granted a connection with a desired resource with complete lack of verification of the validity of the obtained
response. When the concept was designed, no one could predict such rapid popularization of Internet, kinds of
provided services and dangers connected with it. Information sent this way are not confidential or secured against
forgery or modification. Potentially data may be falsified or changed in many areas of the web. After being loaded
to DNS servers cache it is made available for other users.
DNS is currently a mechanism most often used by other Internet protocols/services (for ex: www, http). Until now
the main concern was the security of services like: securing access to bank services, ciphering electronic mail
while omitting to secure internet domain names themselves, which, of course, are the base for all these
mentioned services. This exposes the users to unawarely give away important data (ID, passwords) on phony
internet web pages created on authentic domain names and lose control over for ex: bank accounts, electronic
mail or profile on community portals.
[top]
What benefits does DNSSEC provide?
DNSSEC is an efficient method of increasing the safety while using DNS and thus increasing the safety of
Internet users and institutions that function in the Internet.
DNSSEC is a tool for the end user, who is able to see if the information, which he received via DNS, is true or
false and thus if for example the internet, he entered, is really a webpage of a bank, office, electronic court or a
public register or is a phony webpage (phishing).
DNSSEC is a tool for institutions which function in the Internet, that are particular about the safety of their clients
and provided services.
[top]
How does authorization of data work in DNSSEC?
Process of authorization of the information received via DNS protocol is based on so called "trust chain", which
requires a proper signing of corresponding levels of domain zones, accordingly to the hierarchic structure of DNS.
This means that in order to secure a domain name one must sign the zone for this domain and introduce a
special, cryptographic abbreviation from the public part of the key which signs the zone (Delegation Signer
record) to the zone of the domain parent in the DNS hierarchy, in which the secured domain name was
registered. Here the mentioned abbreviation should be signed by a private key and its abbreviation, analogically,
passed on to the parent zone. Such chain is built up to Root zone (the highest level in DNS hierarchy), where a
"Trust Anchor" (commonly accepted as trusted) key is located.
[top]
How to use DNSSEC?
The .pl domain name Registrant may secure his services, connected with the domain name, by signing its zone
with use of DNSSEC and placing in the parent zone, serviced by NASK, a cryptographic abbreviation (in form of
DS record) from the public part of the key.
The Registrant may sign the zone by himself or ask the Registrar to do it, if this Registrar provides domain name
technical support. In both cases it is the Registrar, which represents the Registrant before NASK or NASK itself,
in case of direct service, that enters the DS record to zones maintained by NASK. On its pages, NASK will inform
about the date, when it will begin to accept DS records from the Registrants of domain names registered in NASK
zones.
The end user, who wants to benefit from DNSSEC, has the ability to use free solutions for internet browsers ( so
called plug-ins), that use DNSSEC extension and warn the user about possible threats.
[top]
How to change name-servers of a .pl domain name, secured by DNSSEC?
(effective from the date of acceptance by NASK DS records from the Registrants)
Delegation changes of .pl domain names, secured by DNSSEC, is reported to NASK in the same manner as
delegation changes of names that are not protected. The Registrant should report the change by the Registrar
(NASK or Partner) that services the .pl domain name. The difference, in case of DNSSEC secured .pl domain
name, relies on conducting, in short period of time, three changes in .pl domain registry: adding new DS record,
change of name servers, removing old DS record.
In case of delegation changes of .pl domain name, secured by DNSSEC, it is essential to maintain extreme
caution so that no errors are made by the technical administrator, that could break the trust chain.
[top]
What deserves extra attention while the change of DNSSEC secured .pl domain name delegation
takes place?
(effective from the date of acceptance by NASK DS records from the Registrants)
Improper configuration of zones during the change of DNSSEC secured .pl domain name delegation may result in
breaking the trust chain, which in turn results in errors during zone validation. Outcome of these errors is an
inability to obtain the IP address on DNS queries.
It is worth to remember that:
change of domain name delegation may not interrupt the process of validation of its zone.;
errors in validation are more dangerous than the lack of possibility of the validation itself, if the
possibility of choosing the lesser evil exists, it is preferred to use an unsecured zone, but such choice
should also be limited to minimum;
critical material in form of parts of private keys, signing the data in the zone, is never exchanged
between technical administrators;
one does not place "unfamiliar" RRSIG records in the serviced zone;
interaction between Registry, Partner, technical administrator and Registrant should be limited to
minimum;
if the interaction cannot be avoided then the new technical administrator should bear the weight of
conducting the delegation change process, releasing the current technical administrator, which loses the
control over .pl domain name service, from this duty;
DNSSEC mechanisms aside, the process of delegation change should look exactly like in the case of
.pl domain name unsecured by DNSSEC.
One should accept the following assumptions:
lack of possibility of direct communication between the current and the new technical administrator of
the .pl domain name;
there is a possibility to include unfamiliar DNSKEY records to the zone to achieve an uninterrupted
validation of trust chain along the DS/KSK/ZSK records, both at the current and the future technical
administrator, with the possibility to sign these DNSKEY records;
both, current and future, technical administrators endorse the same ciphering algorithm;
there is a distinction between ZSK and KSK keys in the zone.
Stages of the change: (takes into account three changes in the .pl domain registry):
in the moment the change starts, the DS record, in the parent zone, points to KSK key which is located
in the zone of technical administrator who loses control over the .pl domain name
new technical administrator, via DNS mechanisms, downloads the ZSK record from the overtaken
(from the current technical administrator) zone. He then verifies its validity via DNSSEC mechanisms,
enters it to the DNSKEY records, placed on his servers, and signs a new set of DNSKEY records with
help of his KSK and ZSK keys.
At this stage the new infrastructure is not yet ready to accept DNS queries and thanks to this procedure
it is possible to validate old RRSIG records using the new KSK and ZSK keys.
Current technical administrator receives from the Registrant a new DNSKEY record, which includes
ZSK key, and enters it to his zone. He then signs this new set of records with his KSK and ZSK keys.
At this stage is it is possible to validate new RRSIG records using old KSK and ZSK keys.
Partner, by Registrant's request, makes the change of delegation of .pl domain name by adding to it a
new DS record, which points to a new KSK key (first change in the .pl domain registry).
At this stage, after the TTL time, determined by old ZSK, the resolvers will not keep DNSKEY records in
its memory or will keep a set of DNSKEY records signed by old KSK key but having a new ZSK key.
If the resolvers memory keeps a set of DS records, which include a abbreviation to new KSK key (old
set of DS records expired), one may change the delegation of .pl domain name and, in it ,point the
servers of new technical administrator (second change in .pl domain registry).
After this step the parent zone will include the delegation to new servers and two new DS records,
pointing to new and old KSK. Thanks to two DS records it is possible to verify both DNSKEY sets.
If all DNSKEY record sets, which include old KSK, expired (DNS resolver of the previous technical
administrator should not respond to DNS queries), Partner, on the Registrant's request, makes the
change in delegation of .pl domain name by removing the old DS record (third change in .pl domain
registry).
Minimum waiting time before executing the last step is a sume of periods:
TTL of the set of NS records existing in the parent zone;
TTL of the set of NS records returned by autoritative server;
TTL of the set of DNSKEY records from the old zone.
If the Registrant can't get in touch with the current technical administrator of the domain name, of if the
administrator refuses to enter a new DNSKEY record in the zone, before the delegation change one must write
the zone off by removing the DS record from the parent zone, change the delegation, change keys to new ones
and once more enter the DS record in the parent zone.
[top]
How to conduct a safe transfer of a domain name, secured with DNSSEC?
(effective from the date of acceptance by NASK DS records from the Registrants)
The .pl domain name transfer procedure remains the same for .pl domains both secured and not secured with
DNSSEC.
If a transfer of .pl domain name secured with DNSSEC is combined with delegation change ( for ex: to the
Partner's NS's) we recommend to make the .pl domain name transfer after the DS record is added to the domain
object (look for: first change in the .pl domain name registry in case of DS change procedure of .pl domain
secured with DNSSEC).
[top]
What should I do if my private keys get compromised?
(effective from the date of acceptance by NASK DS records from the Registrants)
If a situation occurs where one suspects compromise (revelation) of keys, one must make sure if his
infrastructure is secure and then proceed to exchange the keys with an additional option to invalidate the old,
compromised keys by setting the "Revoke" bit on DNSKEY records.
[top]
Which other documents should I get acquainted with?
(effective from the date of acceptance by NASK DS records from the Registrants)
DNSSEC Policy and Practice Statement Framework is a description of procedures and rules used in .pl domain
zone, secured with DNSSEC. This document is to be used in respect to zones administrated by NASK. Full list of
zones, which are administered by NASK, is available here http://www.dns.pl.
[top]
2011
