DNS Architecture Review

In most organisations, DNS has grown organically. There is a router that handed out DHCP leases at some point. Then came a Windows Server with Active Directory. At some point the hosting provider took over the zone. At some point someone added 8.8.8.8 as a resolver because something stopped working. The result is a DNS infrastructure that nobody fully oversees – and that nobody can assess with confidence during an incident.

The DNS Architecture Review provides that overview. We analyse how DNS is actually set up at your organisation – internally and externally – and document the architecture so that it can actually be used as a working and evidence document in day-to-day operations.

Do internal clients use their own resolver or query public DNS servers directly? Is there a clean separation between an internal zone (e.g. corp.example.com) and the public zone (example.com)? In Active Directory environments, DNS integration with the domain controller is a frequent source of error: competing resolvers, misconfigured zones and uncontrolled forwarders are common findings.

We document the current state and assess whether the internal DNS configuration is viable from a security and operations perspective.

Which resolver is used for outbound queries – ISP resolver, public DNS or your own forwarder? Is DNSSEC validation performed actively, and at which point? Are DNS-over-TLS or DNS-over-HTTPS in use? Who has access to resolver logs, and are the logs stored at all?

The latter is not an academic question: in the context of NIS2 and DORA, DNS logs are a valuable detection source for attacks – C2 traffic and DNS tunnelling leave traces in resolver logs that should be visible in the SIEM.

Are DHCP leases automatically registered in DNS (Dynamic DNS)? If so: is this process secured, or can any device on the network create arbitrary DNS records? In Active Directory environments, uncontrolled DDNS is a widespread and underestimated attack scenario.

In MSP setups, an additional issue is often that it is unclear who actually manages DHCP – the customer, the MSP or a router in the basement. We clarify these responsibilities and assess the technical safeguards.

Where are the authoritative nameservers for public domains located – at the registrar, at the hosting provider, self-operated? Is there a primary and a secondary nameserver that is truly independent? Are zone transfers (AXFR/IXFR) restricted to authorised secondary nameservers – or are they open?

Open zone transfers are a frequent and underestimated finding: they give attackers a complete list of all internal hostnames and IP addresses. We inspect the authoritative infrastructure for consistency, redundancy and access controls.

Is there active monitoring for DNS availability? Is it documented who is responsible for DNS incidents – internally, the MSP or the hosting provider? How long would it take to notice a DNS outage? Is there a documented process for DNS-related incidents?

These questions look organisational but have direct technical consequences: without documented responsibilities and without monitoring, the mean time to detect for DNS incidents grows considerably – with direct impact on compliance evidence under NIS2 and DORA.

DNS infrastructure is often implicit in regulatory frameworks but rarely addressed explicitly. As a result, DNS is missing from asset inventories, risk analyses and incident plans – even though DNS is a central availability component of every internet-based service. The following positioning is a technical assessment; it does not replace legal advice.

NIS2 requires affected companies to have a complete picture of their network and information security – including dependencies on service providers and infrastructure operators (Art. 21 NIS2). DNS dependencies are among them: the registrar, the hosting provider, the resolver operator. Organisations without documented DNS architecture cannot reflect these dependencies completely in their risk analysis. NIS2 also requires measures for attack detection; DNS logs are – when they exist and are evaluated – a valuable detection source.

DORA demands a complete capture of all critical ICT dependencies as part of ICT risk management. DNS belongs to those dependencies but is missing in many ICT asset registries at financial undertakings. DORA also requires the definition of RTOs for critical services and their periodic review. Without knowledge of your DNS architecture, no credible statements about failure probabilities and recovery times can be made.

Telecommunications operators must develop security concepts under §166 TKG that document and protect the integrity and availability of their networks. For TKG-regulated operators, DNS is not peripheral infrastructure but a core element of network communication. A structured DNS architecture documentation – internal, external, authoritative, recursive – is a sensible basis for a defensible TKG security concept.

Manufacturers of connected products that rely on DNS for services, updates or telemetry must document and assess these dependencies as part of Security by Design. A product depending on external DNS services without knowing or monitoring this dependency will struggle to meet CRA requirements in full. The DNS Architecture Review identifies these dependencies systematically.

1. Kick-off call – Clarify scope, network environment and target infrastructure. Free of charge, approx. 30–45 minutes, remote.

2. Structured data collection – We work with a proven questionnaire and supplementary technical queries. Depending on scope, remote or hybrid (e.g. half a day on site). Full system access is not required.

3. Architecture documentation – Structured documentation of your DNS architecture: internal DNS, external DNS, resolver configuration, DHCP integration, authoritative infrastructure, responsibilities. Format: a usable working and evidence document, not a presentation deck.

4. Action catalogue – Prioritised list of identified weaknesses and recommended actions, classified by criticality and effort.

5. Results review – Joint walkthrough of the documentation and the action catalogue. Remote or on site, approx. 90 minutes.