DNS Security Audit

The DENIC incident of 5 May 2026 made it clear: a correctly configured domain can become unreachable within minutes because of an issue in upstream infrastructure – without the domain operator doing anything wrong. The decisive question is not whether something similar will happen again. The question is whether you will notice it – and whether your configuration contains unnecessary risks that would make such an incident worse.

The DNS Security Audit is delivered as a clearly scoped one-off project. It inspects your external DNS configuration for weaknesses that rarely show up in day-to-day operations – but that can make the difference between a controlled response and an uncontrolled outage during an incident.

Is DNSSEC enabled for your domain – and is it configured correctly? A non-validating DNSSEC entry is more dangerous than no DNSSEC at all: validating resolvers such as Google DNS (8.8.8.8), Cloudflare (1.1.1.1) or Quad9 (9.9.9.9) will reject your domain with SERVFAIL, while non-validating resolvers continue to resolve it. The result is a selective and hard-to-diagnose outage.

We inspect DNSKEY records, RRSIG signatures, DS delegation and NSEC/NSEC3 configuration for consistency and validity – on the basis of publicly retrievable DNS data at the time of analysis.

Which resolvers do your employees, systems and customers use? Is there an uncontrolled mix of ISP resolvers, public DNS and internal forwarders? Resolver dependencies determine which user groups are affected by a DNS incident – and which are not.

We document the resolver landscape based on the information you provide and assess its risk profile with regard to availability, validation behaviour and data protection.

How many authoritative nameservers are configured – and are they actually independent? A nominally present secondary nameserver hosted by the same provider as the primary offers no real redundancy.

We inspect SOA records, TTL values, NS consistency between registrar and authoritative server, and indicators for geographic and infrastructural independence of nameservers – as far as they are visible in publicly available data.

Is there active monitoring for the DNS availability of your domain? Is DNSSEC validation being monitored? Who would notice a DNS outage first – your monitoring system or your customers? Insufficient or missing DNS monitoring is one of the most frequent findings – and at the same time one of the areas where improvements can be made fastest.

We assess the status of your DNS monitoring based on the information you provide and identify concrete gaps that should be addressed.

DNS security is not an isolated technical topic. Several regulatory frameworks address the availability and security of DNS infrastructure directly or indirectly. In the audit we position the findings within these frameworks. This positioning is a technical assessment; it does not replace legal advice.

NIS2 obliges affected companies to implement appropriate technical and organisational measures to protect network and information security. This includes measures to ensure the availability of services (Art. 21 NIS2). DNS is a central availability component of every internet-based service. The DENIC incident has shown that operators who are not directly affected can still fail because of upstream infrastructure issues. NIS2-affected companies should know and be able to monitor their DNS dependencies.

For financial undertakings and their ICT service providers, DORA requires ICT risk management that captures all critical dependencies. DNS is such a dependency – but is often missing from asset registries in practice. DORA also requires the definition of Recovery Time Objectives (RTOs) for critical services; without an assessment of DNS response during incidents these RTOs cannot be set credibly. The audit provides a technical basis for this.

Telecommunications operators are obliged under §166 TKG to develop and implement security concepts ensuring the availability and integrity of their communications networks. DNS is an integral part of every communications network. Defects in DNSSEC configuration or insufficient resolver redundancy are weaknesses that should be addressed in the security concept.

Manufacturers of connected products must ensure under the Cyber Resilience Act (CRA) that their products communicate securely – including secure name resolution. Products with DNS dependencies on external services should document and secure those dependencies. The audit identifies such dependencies as the basis for product-specific risk assessment.

1. Kick-off call – Clarify scope and target domains, questions about the existing infrastructure, scheduling. Free of charge, approx. 30 minutes, remote.

2. Technical analysis – Remote analysis of your DNS configuration based on publicly visible records and, where required, supplementary information that you provide (e.g. internal resolver configuration). No system access required.

3. Findings report – Structured report with assessment of all areas examined, prioritised actions and concrete recommendations. A usable working document rather than an academic paper.

4. Results review – Joint walkthrough of the results, clarification of open questions, definition of next steps. Remote, approx. 60 minutes.