On Friday an administrator moves the company domain’s zone to a new DNS operator and checks from a laptop that the website works. On Monday some customers report that the site does not respond, while for others everything is fine. The cause is a DS record in the .pl zone that still points to the old operator’s key: resolvers that check signatures treat the new answers as forged and refuse to return them.
In cybersecurity, DNSSEC is often presented as a way to secure a domain. More precisely, it is a signature on DNS answers: it confirms where they come from, but it does not hide them and it will not stop someone who logs in to the registrar’s panel. Enabling it for a .pl domain takes cooperation between the DNS operator and the registrar, and getting the steps in the wrong order cuts the domain off from some users.
What is DNSSEC and how does the chain of trust work?
DNSSEC (Domain Name System Security Extensions) is a set of extensions to the DNS protocol that makes it possible to verify that an answer comes from the zone owner and was not altered on the way. The core specification consists of RFC 4033, 4034 and 4035 from March 2005. RFC 9364 from February 2023 (BCP 237) brings the whole family together in one place.
The operator signs every record set in the zone, and the signature goes into an RRSIG record; the zone’s public keys sit in DNSKEY records. The parent zone holds a DS record, which is a cryptographic digest of the child zone’s key. According to NASK, this chain runs all the way up to the root zone, whose key acts as the commonly recognised trust anchor.
A validating resolver checks the chain from the top: the root key confirms the DS of the .pl zone, the .pl key confirms the DS of your domain, and your domain’s key confirms the record signatures. If any link does not match, the answer fails validation. That is why an error in the DS record in the parent zone cuts the whole domain off from validating resolvers.
Zones typically separate the key that signs records (ZSK) from the key that signs the DNSKEY set (KSK), whose digest goes into the DS record. RFC 4033 notes that this split is purely operational and a single key can play both roles.
What does DNSSEC protect against?
DNSSEC protects against forged DNS answers: a validating resolver rejects a record whose signature does not match the key from the chain of trust. RFC 4033 describes this as data origin authentication and integrity protection for DNS data. An attacker can send a fake answer but cannot forge a signature without the zone’s private key. Thanks to NSEC records the same applies to negative answers: nobody can “switch off” a record by pretending it does not exist.
The most obvious example is DNS poisoning, which means injecting false records into a resolver’s cache. Without DNSSEC a resolver has no cryptographic way to tell a bank’s real address from a substituted one. With DNSSEC a record without a valid signature does not reach the user. Of the techniques the glossary groups under DNS attack, signatures cover exactly those that rely on forging answers.
The protection works only when both sides do their part: the zone is signed and the resolver checks signatures. Estimates cited in RFC 9364 (February 2023) put the share of signed domain names used for websites at fewer than 10%, with only around a third of queries to recursive resolvers validated. A signed domain therefore protects the users whose resolver validates, and nobody else.
What doesn’t DNSSEC protect against?
DNSSEC does not provide confidentiality: RFC 4033 states plainly that the extensions do not encrypt data, and its security section adds that this was a deliberate design choice. The content of queries and answers stays visible to anyone who can see the traffic.
The same document lists further limits. DNSSEC offers no protection against denial of service, and handling signatures opens an additional class of DoS attacks based on expensive cryptographic operations. The chain of NSEC records makes it possible to enumerate every name in a zone, which helps an attacker map the infrastructure. Data at the delegation point also remains unsigned, namely the NS and glue records in the parent zone.
The most important limit, however, is not in the RFC, because it follows from the definition itself. DNSSEC confirms that a record was signed with the zone’s key, not that the domain owner wanted to change it. Whoever takes over the account in the registrar’s or DNS operator’s panel can change records, and an operator that signs the zone automatically will give them a valid signature; they can also replace the name servers and remove the DS record. To the resolver, everything will look correct. That is why access to the registrar’s and DNS operator’s panels should be protected with multi-factor authentication (MFA) and limited to a short list of people, and it is worth asking the registrar whether changes to the domain can be locked.
For the same reason DNSSEC cannot tell an honest domain from a lookalike. An attacker who registers a name with a typo can sign it just like the real bank. A signature says who is responsible for the zone, not whether it deserves trust.
Key points:
- DNSSEC signs DNS answers and makes it possible to detect tampering on the way.
- It does not encrypt queries, protect against DoS or hide the names in a zone.
- It will not defend a domain when an attacker logs in to the registrar’s or DNS operator’s panel.
- It works only for users whose resolver checks signatures.
How is DNSSEC different from DNS encryption?
DNSSEC signs data, while DNS over TLS and DNS over HTTPS encrypt the channel between a computer and its resolver, so they solve two different problems. DNS over TLS is specified in RFC 7858 from May 2016, and DNS over HTTPS in RFC 8484 from October 2018. Both hide the content of a query from an observer on the local network or at the internet provider.
Encryption, however, says nothing about whether the answer is genuine. If the resolver holds a poisoned record in its cache, an encrypted channel will deliver the false address just as efficiently as the real one. DNSSEC works the other way round: everyone can see the answer, but nobody can change it unnoticed.
The two mechanisms meet on the last hop. If the user’s computer does not check signatures itself, it trusts the resolver, which sets the AD flag in the answer. RFC 4033 notes that the channel between them does not need confidentiality, but it does need data integrity and message authentication. That gap is closed only by a protected channel to a trusted validating resolver.
How do you check whether a domain has DNSSEC enabled?
The quickest way is to look for the domain’s DS record in the parent zone and for the AD flag in an answer from a validating resolver. All you need is the dig tool from the BIND utilities.
The command dig DS example.pl +short returns the DS record from the .pl zone. An empty answer means the chain of trust does not reach your domain: the zone is not signed or nobody has passed the key digest to the registry. The command dig example.pl SOA +dnssec shows whether RRSIG signatures arrive alongside the records, and an ad flag in the answer header means the resolver has checked the whole chain. A missing flag may simply be the fault of a resolver that does not validate, in which case the test should be repeated from another one.
RFC 4033 describes four states of data as seen by a validating resolver: secure, insecure, bogus and indeterminate. A resolver signals the bogus state with a server failure (SERVFAIL). If a domain returns that error but answers correctly with the +cd option, which disables signature checking, the DNSSEC configuration is to blame.
How do you enable DNSSEC for a .pl domain?
For a .pl domain, DNSSEC is enabled in two places: the DNS operator signs the zone, and the registrar passes a key digest to NASK, which ends up in the .pl zone as a DS record. According to NASK’s instructions, the digest is submitted through the registrar that manages the domain. The exception is names under .gov.pl, for which the digest is submitted directly to NASK with a request to change the delegation.
If the registrar is also the DNS operator, both steps are often handled in one panel. If someone else hosts the zone, the order matters: first a signed zone with verified signatures, and only then the DS record at the registrar. The reverse order will make validating resolvers start rejecting answers.
Before the deployment you also need to decide who holds the keys. When the operator signs, the company depends on its procedures. When the company signs itself, for example on BIND servers (NASK recommends the latest stable version), it takes on key rollovers and keeping track of signature validity.
Which signing algorithm should you choose?
For a new zone, choose algorithm 13 (ECDSA P-256 with SHA-256), 8 (RSA/SHA-256) or 15 (Ed25519): RFC 9904 from November 2025 marks all three as recommended for signing, and NASK accepts them in DS records. RFC 9904 obsoleted RFC 8624 and moved the list of recommendations to the IANA registries, so the registry, not an older guide, decides an algorithm’s status.
According to the same document, algorithms 5 (RSASHA1) and 7 (RSASHA1-NSEC3-SHA1) are not recommended for signing, and algorithms 1 (RSA/MD5) and 3 (DSA) are prohibited. For the digest in a DS record, SHA-256 is recommended, while SHA-1 must not be used for delegation. A zone once signed with algorithm 5 or 7 still works, but needs a migration plan.
NASK writes that in practice algorithm 8 with RSA keys of at least 2048 bits is the most common, and advises considering algorithm 13: at a comparable level of security it produces smaller signatures. It stresses that there is no universal recommendation.
Changing the algorithm in a live zone is a separate operation. RFC 9904 points to RFC 6781 and RFC 7583 and warns that changing the digest algorithm of the DS record at the same time as rolling the KSK leads to validation failures. So the DS algorithm is changed first, and only then the key.
What can go wrong when deploying DNSSEC?
The biggest DNSSEC risk is your own configuration error: RFC 4033 warns that configuration errors can make validating resolvers treat entire legitimate zones as unreachable. No attacker is needed.
The bogus state is caused, among other things, by missing or expired signatures and by algorithms the resolver does not support. Expired signatures appear, for example, when the re-signing automation stops working: the zone does not change, but the signatures lose validity and the domain disappears for part of the internet. Monitoring signature expiry is therefore as necessary as monitoring TLS certificates.
The second source of outages is key rollover. NASK describes the usual methods: for ZSK keys most often pre-publishing the new key (Pre-Publish), and for KSK keys the double-signature method (Double Signature). The registry itself, in its document “DNSSEC Polityka i Zasady Postępowania” (version 2.0 of 12 March 2020), declares that ZSK keys of the .pl zone are rolled every 6 months and KSK keys every 12 months.
The third risk is a change of DNS operator, which is the scenario from the introduction. NASK warns that a mistake when changing the delegation of a signed domain breaks the chain of trust and the resolver returns no IP address. The registry states a principle: validation errors are more dangerous than no validation, so if you must choose the lesser evil, it is better to leave the zone unsigned for a short time. When the current operator does not cooperate, the NASK procedure begins with removing the DS record, which returns after the delegation change and the key rollover.
Do regulations require DNSSEC?
As of 14 November 2026, neither the NIS2 directive nor Commission Implementing Regulation (EU) 2024/2690 names DNSSEC. The regulation does, however, require some entities to apply best practices for DNS security.
In Annex I, in the digital infrastructure sector, NIS2 covers DNS service providers (excluding operators of root name servers) and TLD name registries. Under Article 1, Regulation 2024/2690 applies to, among others, DNS service providers, TLD registries, cloud and data centre service providers, and managed service providers, including managed security service providers. Point 6.7.2(l) of its Annex requires them to apply best practices for DNS security.
The regulation does not say what the best practice is. RFC 9364, however, says it plainly: using DNSSEC is the best current practice for origin authentication of DNS data, and at the time of its publication no Standards Track RFC offered any other method. A managed service provider whose domains are not signed should therefore have a justification ready for the auditor’s question.
In Poland, the same entities, if they are essential or important, are listed in Article 8b(1) of the Act on the National Cybersecurity System, added by the amendment of 23 January 2026 (Journal of Laws 2026, item 252): they must apply the measures from Regulation 2024/2690. Neither the directive nor the regulation obliges other companies to deploy DNSSEC directly. For them it is a risk-based decision: the more customers rely on the domain for logins, payments and email, the greater the benefit of a signature.
How do you plan a DNSSEC deployment step by step?
A DNSSEC deployment is planned as a process with an owner for every stage, because it requires cooperation between the registrar, the DNS operator and the IT team, and a gap between them is enough for an outage.
| Stage | Who is responsible | What to check before moving on | Typical mistake | Evidence of completion |
|---|---|---|---|---|
| Domain inventory | domain owner and IT | registrar and DNS operator for each domain, support for DNSSEC and DS forwarding | domains left with a former registrar | list of domains with registrar, operator and contact |
| Key decision | IT and security | who generates and stores the keys, how they are rolled | knowledge of the keys held by one administrator only | documented key rollover procedure |
| Zone signing | DNS operator | algorithm recommended in the IANA registry (8, 13 or 15), signatures on all records | algorithm 5 or 7 from an old guide | output of dig … +dnssec with RRSIG records |
| DS submission | registrar | DS matching the current KSK, SHA-256 digest | DS with a SHA-1 digest or pointing to an inactive key | DS record visible in the .pl zone |
| Validation test | IT | ad flag from a validating resolver, no SERVFAIL | test from a resolver that does not validate | dated test record |
| Monitoring | IT | signature validity dates, consistency of DS and DNSKEY | customers are the ones who report the outage | alert before signatures expire |
| Change of operator or registrar | domain owner and both operators | NASK procedure: new DS before the delegation change, waiting out the TTLs | changing name servers without updating the DS | change plan with dates |
The last row needs the most attention: a change of operator happens rarely, so the procedure with TTL timings has to exist in writing before it is needed.
Key points:
- First a signed and verified zone, then the DS record at the registrar.
- Choose the algorithm according to the current IANA registry, not old guides.
- Monitor signature validity and have a procedure for changing DNS operator.
How can nFlo help with network security?
nFlo is neither a domain registrar nor a DNS operator, so you enable DNSSEC with your own registrar and operator. As part of its network security service, nFlo audits and secures the infrastructure a company already has: network segmentation, Zero Trust architecture, DDoS protection, BGP routing security, and firewalls and IPS/IDS systems.
A signature on DNS answers does not replace the other layers of network protection. We describe those layers, from segmentation to DDoS protection, in the network security section of our knowledge base. If you want to check how well your company’s network is secured, contact us.
What else is worth knowing about DNSSEC?
Does DNSSEC encrypt DNS queries?
No. RFC 4033 states that the DNSSEC extensions do not provide confidentiality: they sign data but do not hide it. Encryption of the channel between a computer and its resolver is provided by DNS over TLS (RFC 7858) and DNS over HTTPS (RFC 8484).
Does DNSSEC protect against phishing?
Partly. It protects against forged answers for the genuine domain, provided the user’s resolver validates signatures. It does not protect against a lookalike domain registered by the attacker, because such a domain can be signed as well.
Does every .pl domain registrar support DNSSEC?
Not necessarily. DNSSEC support and forwarding of DS records to NASK have to be checked with the specific registrar, because the registrar passes the key digest to the registry. NASK recommends checking, before a domain transfer, that the new registrar offers forwarding of DS records.
What happens if DNSSEC signatures expire?
Validating resolvers treat the answers as invalid, because RFC 4033 lists expired signatures among the causes of the bogus state. They return a server failure and the domain stops resolving for their users.
Is DNSSEC mandatory?
As of 14 November 2026, neither the NIS2 directive nor Commission Implementing Regulation (EU) 2024/2690 names DNSSEC. The regulation does, however, require DNS service providers, cloud providers and managed service providers, among others, to apply DNS security best practices.
