DNS and compliance: DNSSEC, ANSSI, NIS2 and GDPR for resolver operators

DNS occupies an awkward seat at the compliance table. On one side it's a security control — the place you can block malicious infrastructure and watch for compromise. On the other, every query is a record of who looked up what, which makes your resolver a producer of personal data. Most frameworks pull on both threads at once: do more to secure name resolution, and be disciplined about the logs that security generates.

Four frameworks come up again and again for anyone running a resolver in Europe: DNSSEC for integrity, the ANSSI hygiene guidance for baseline practice, the NIS2 directive for governance, and GDPR for the data. Here's what each actually asks of your DNS, and the concrete controls that answer them — without the legalese.

DNSSEC — integrity, not privacy

DNSSEC (RFC 4033–4035) signs DNS records cryptographically so a resolver can verify that an answer really came from the zone's owner and wasn't tampered with in transit. A chain of signatures runs from the root down to the domain; a validating resolver checks that chain and refuses forged answers. It is the defence against cache poisoning and on-path answer injection.

Two things people consistently get wrong about it:

• DNSSEC is not encryption. It authenticates answers; it does nothing to hide your queries. Confidentiality is the job of encrypted transport (DoH/DoT/DoQ). The two are complementary — DNSSEC proves the answer is genuine, encrypted DNS keeps the question private.
• Validating and signing are different roles. Validating inbound answers protects your users and is low-risk. Signing your own zone protects everyone who looks you up — but a fumbled signing setup (an expired signature, a botched key rollover) takes the zone offline with SERVFAIL. Real outages at large operators have come from exactly this.

NIS2 — governance catches up with DNS

The NIS2 directive (EU 2022/2555, transposition deadline October 2024) widened the EU's cybersecurity rules to medium and large entities — roughly 50+ staff or €10M+ turnover — across 18 sectors. If you're in scope, Article 21 sets out the minimum risk-management measures you must take. Several map cleanly onto DNS-layer controls:

NIS2 also tightens incident reporting (Article 23): an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month. You can't report what you didn't record — which is precisely why query logging and a real-time view of blocked/anomalous lookups stop being "nice to have" and become part of the evidence base. DGA and phishing flags surfaced at the resolver are early-warning signals in the NIS2 sense.

ANSSI — the French baseline

For deployments in France, ANSSI (the national cybersecurity agency) sets the practical bar. Its Guide d'hygiène informatique and related recommendations don't single DNS out for special treatment so much as fold it into good hygiene, and the direction is consistent:

• Control egress DNS. Devices should resolve through a known, managed resolver — not whatever public server they please. That means redirecting or blocking rogue DNS at the network edge and closing client-side bypass routes.
• Encrypt the resolver path. Protect queries in transit; don't leave name resolution in clear text on the wire.
• Log what matters, centrally. ANSSI's logging guidance wants events recorded, time-synchronised and retained long enough to investigate — but no longer than necessary.
• Cyber hygiene basics. Known-bad blocking, segmentation, least privilege — the resolver is one clean place to enforce several of these for the whole network at once.

None of this is exotic. It's the same shortlist a competent administrator would write anyway; ANSSI just makes it the expected baseline rather than an optional extra.

GDPR — your query logs are personal data

Here's the tension. Everything above pushes you to log more. GDPR pushes back: a DNS query log pairs a client IP with the domains it looked up, and that combination is both personal data (an IP address is personal data under settled case law) and unusually revealing — browsing patterns, health, religion, and political interests can all be inferred from domains alone.

So the logging that helps your security case is also a privacy liability. GDPR's Article 5 principles tell you how to hold it responsibly:

The practical reconciliation is aggregation plus retention limits. Granular per-query records are what you need for a live incident; weeks later you only need the trends. UnveilDNS rolls detailed query data into daily summaries and ages out the raw per-query tables behind them, so you keep the operational picture and the audit trail without hoarding everyone's browsing history forever. Restricting access to the logs and stating a clear retention period turns "we log DNS" from a liability into a defensible, documented control.

Security frameworks ask you to see more; privacy law asks you to keep less. The answer isn't to pick a side — it's to log granularly, retain briefly, aggregate for the long term, and write the retention period down.

The one-page mapping

Compliance frameworks have a reputation for demanding things engineers would never choose. DNS is the rare case where they mostly ask for what you'd want anyway: prove the answers are genuine, keep the questions private, block the obviously hostile, see what's happening, and don't keep the evidence one day longer than you need it. A resolver that does all of that isn't a compliance cost — it's a control you'd run regardless, with the paperwork already attached.