Why DNS security becomes urgent in real enterprise networks

In the beginning, DNS is “just working.” A few servers, a few applications, a few sites. Then the organization grows. We add remote offices, VPNs, cloud workloads, SaaS integrations, and internal APIs that were never meant to be exposed. Over time, DNS quietly becomes the control plane for almost everything: authentication flows, service discovery, software updates, and the paths our users take to reach critical systems.

That is exactly why DNS becomes a security problem without anyone noticing. A single poisoned response, a misdirected query leaving the network, or an internal hostname accidentally resolvable from the wrong place can turn into credential theft, lateral movement, data exfiltration, or a long outage that looks like “the network is down.”

We are going to secure DNS resolution on Windows Server in a way that scales: controlled recursion, hardened forwarding, logging and auditing, and a split-DNS architecture that cleanly separates internal and external answers without relying on “Public DNS only.”

Architecture we are implementing

We will implement an enterprise DNS design with two clear roles:

• Internal DNS resolvers (Windows Server DNS) that provide recursion for corporate clients and authoritative answers for internal zones.
• Split-DNS so the same name can resolve differently depending on where the query originates (internal network vs. external/public context), without leaking internal records.

In practice, split-DNS usually means one of these patterns:

• Same zone name, different answers: e.g., app.company.com resolves to an internal VIP inside the network, and to a public WAF outside.
• Internal-only zones: e.g., corp.company.com exists only internally and is not published externally.

On Windows Server DNS, we will implement split-DNS by hosting internal zones on internal DNS servers and ensuring external DNS is hosted separately (often at an authoritative DNS provider or perimeter DNS). The key is not the provider; the key is that internal DNS servers never become a general-purpose resolver for the internet and never leak internal zone data.

Prerequisites and assumptions

Before we touch configuration, we need to be explicit about the environment. DNS is foundational; “almost correct” is how outages happen.

• Operating system: Windows Server 2019 or Windows Server 2022 (Desktop Experience or Server Core). The commands below use PowerShell and built-in Windows features available on both.
• Role: We will install and configure the DNS Server role. If Active Directory is present, we will integrate where appropriate, but the steps also work for standalone DNS with file-backed zones.
• Permissions: We must run PowerShell as Administrator. In domain environments, we should use an account with rights to manage DNS (typically Domain Admins or delegated DNS Admins).
• Network: The DNS server must have a static IP. Clients must be configured (via DHCP options or static settings) to use only our internal DNS resolvers.
• Time: Correct time sync is required (Kerberos, AD-integrated DNS replication, and reliable logging). Ensure Windows Time is healthy.
• Change control: We should schedule a maintenance window if this server is already serving production clients. DNS changes can have immediate blast radius.
• Security baseline: We assume Windows Defender and Windows Firewall are enabled unless an enterprise endpoint platform replaces them. We will explicitly validate firewall rules for DNS.

We will also assume we have two upstream DNS resolvers available for forwarding. In enterprise environments these are typically security-filtering resolvers, perimeter resolvers, or dedicated recursive resolvers. We will not rely on “Public DNS only.”

Step 1: Install DNS Server role and management tools

First we install the DNS Server role. We do this explicitly so the server can host internal zones and provide controlled recursion for our clients. We also install management tools so we can manage the server locally or via remote administration.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Install-WindowsFeature -Name DNS -IncludeManagementTools"

This installs the DNS Server service and the DNS management components. The DNS service will be available for configuration, and the server can now host zones and answer queries.

Now we confirm the role is installed and the service is running.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-WindowsFeature DNS | Format-List DisplayName,InstallState; Get-Service DNS | Format-List Name,Status,StartType"

This confirms the DNS role state and whether the DNS service is running and set to start automatically.

Step 2: Confirm the server has a static IP and identify the active interface

DNS servers must not change IP addresses. Before we proceed, we confirm the active interface and current IP configuration. We will use this information later for firewall scoping and for validating client paths.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-NetIPConfiguration | Where-Object { $_.IPv4Address -and $_.NetAdapter.Status -eq 'Up' } | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DNSServer"

This prints the active interface alias, IP address, gateway, and current DNS settings. If the server is using DHCP for its own IP, we should stop here and correct that before continuing.

Step 3: Lock down recursion and restrict who can query us

In enterprise networks, the most common DNS security failure is an internal DNS server that accidentally becomes an open resolver for networks that should never use it. We will do two things:

• Restrict recursion to our internal networks only.
• Restrict which clients can query the server at all.

First, we identify the server’s current DNS recursion configuration so we know what we are changing.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-DnsServerRecursion | Format-List *; Get-DnsServerSetting -All | Select-Object Name,EnableDnsSec,EnableEDnsProbes,EnableIPv6,EnableRRL,NoRecursion,SecureResponses | Format-List"

This shows whether recursion is enabled and highlights server-wide settings that influence response behavior.

Define internal networks for recursion and query access

Now we define the internal subnets that are allowed to use this DNS server. We will create a reusable PowerShell variable so the commands remain copy/paste-safe. We should edit the CIDRs to match our environment before running the “set” commands.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$InternalSubnets = @('10.0.0.0/8','172.16.0.0/12','192.168.0.0/16'); $InternalSubnets"

This creates an internal subnet list. In production, we should replace these with the exact enterprise ranges (including branch office ranges and VPN pools) rather than broad RFC1918 blocks if we want tighter control.

Next, we apply these subnets to recursion scope and query access. This ensures only our internal networks can use recursion and query the server.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$InternalSubnets = @('10.0.0.0/8','172.16.0.0/12','192.168.0.0/16'); Set-DnsServerRecursion -Enable $true -SecureResponse $true; Set-DnsServerSetting -All -RecursionTimeout 8 -MaxCacheTtl ([TimeSpan]::FromHours(24)) -MaxNegativeCacheTtl ([TimeSpan]::FromMinutes(15)) -EnableDnsSec $true; Set-DnsServerClientSubnet -Name 'InternalNetworks' -IPv4Subnet $InternalSubnets -ErrorAction SilentlyContinue; Set-DnsServerClientSubnet -Name 'InternalNetworks' -IPv4Subnet $InternalSubnets -ErrorAction Stop"

This enables recursion with secure responses, enables DNSSEC validation support at the server setting level, and defines a named client subnet group. We also set conservative cache TTL limits to reduce the blast radius of bad data while still keeping performance strong.

Now we restrict recursion and query access to internal networks. Windows DNS supports these controls via server settings and policies. We will use DNS policies to explicitly allow recursion only for internal clients and deny it for everything else.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Add-DnsServerQueryResolutionPolicy -Name 'AllowRecursion-Internal' -Action ALLOW -ApplyOnRecursion -ClientSubnet 'eq,InternalNetworks' -ErrorAction SilentlyContinue; Add-DnsServerQueryResolutionPolicy -Name 'DenyRecursion-NonInternal' -Action DENY -ApplyOnRecursion -ClientSubnet 'ne,InternalNetworks' -ErrorAction SilentlyContinue; Get-DnsServerQueryResolutionPolicy | Select-Object Name,Action,ApplyOnRecursion,ClientSubnet | Format-Table -AutoSize"

This creates two explicit rules: internal clients are allowed to recurse, and everything else is denied recursion. The final command lists the policies so we can confirm they exist and are applied.

Step 4: Configure controlled forwarding to upstream resolvers

Enterprises rarely want every internal DNS server to talk directly to the entire internet. Forwarding gives us control: we can centralize filtering, logging, and egress policy. We will configure forwarders to our approved upstream resolvers.

First, we inspect current forwarders and root hints. This tells us whether the server is already forwarding or attempting iterative resolution.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-DnsServerForwarder | Format-Table -AutoSize; Get-DnsServerRootHint | Select-Object NameServer,IPAddress | Format-Table -AutoSize"

This shows existing forwarders and the configured root hints. If no forwarders exist, the server may attempt iterative resolution using root hints, which is often not desired in tightly controlled enterprise networks.

Now we set forwarders. Because upstream IPs vary by environment, we will first print a template variable and then apply it. We should replace the example IPs with our real upstream resolvers before running the set command.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$UpstreamResolvers = @('10.20.30.40','10.20.30.41'); $UpstreamResolvers"

This defines the upstream resolver list. In production, these should be highly available resolvers reachable from this DNS server (often a pair in separate sites).

Next, we apply the forwarders and disable fallback to root hints. This ensures queries go only where we intend.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$UpstreamResolvers = @('10.20.30.40','10.20.30.41'); Set-DnsServerForwarder -IPAddress $UpstreamResolvers -UseRootHint $false -PassThru | Format-List"

This configures the DNS server to forward queries to the specified upstream resolvers and not use root hints as a fallback. The output confirms the forwarders now in effect.

We verify forwarding behavior by resolving a known external name and confirming the server answers successfully. We will query the local DNS server explicitly.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Resolve-DnsName -Name example.com -Server 127.0.0.1 -Type A | Select-Object Name,Type,IPAddress | Format-Table -AutoSize"

If this succeeds, the server is resolving via the configured forwarders. If it fails, we will address it in troubleshooting (usually firewall, routing, or upstream policy).

Step 5: Implement split-DNS for internal and external resolution

Split-DNS is where enterprise DNS becomes “quietly powerful.” We want internal clients to reach internal endpoints, while external users reach perimeter endpoints, even when the hostname is the same. The security win is that internal records never need to be exposed externally, and internal routing stays internal.

We will implement split-DNS by hosting an internal zone on our Windows DNS server. Externally, the same zone (or selected records) will exist on external authoritative DNS. The two are intentionally different.

Create an internal zone for split-DNS

First, we decide the zone name. A common pattern is to use the same public domain (for example, company.com) internally, but with internal-only records for services. Another pattern is to use a dedicated internal subdomain (for example, corp.company.com). We will demonstrate with a dedicated internal subdomain because it reduces accidental overlap and makes governance easier.

We will create an AD-integrated zone if the server is a domain controller and DNS is integrated with AD. If this server is not a DC, we will create a standard primary zone. We will detect which path we are on.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$IsDC = (Get-WindowsFeature AD-Domain-Services).InstallState -eq 'Installed'; $IsDC"

This prints whether AD DS is installed. If it returns True, we can use AD-integrated zones. If it returns False, we will use a standard primary zone.

Now we create the internal zone corp.company.com. We will run one of the following commands based on the result above.

If AD DS is installed, we create an AD-integrated zone with secure dynamic updates.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$ZoneName = 'corp.company.com'; Add-DnsServerPrimaryZone -Name $ZoneName -ReplicationScope 'Domain' -DynamicUpdate 'Secure' -ErrorAction SilentlyContinue; Get-DnsServerZone -Name $ZoneName | Format-List ZoneName,ZoneType,IsDsIntegrated,DynamicUpdate,ReplicationScope"

This creates an AD-integrated zone replicated within the domain and allows only secure dynamic updates, which is the enterprise-safe default.

If AD DS is not installed, we create a standard primary zone and disable dynamic updates unless we have a controlled need for them.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$ZoneName = 'corp.company.com'; Add-DnsServerPrimaryZone -Name $ZoneName -ZoneFile ($ZoneName + '.dns') -DynamicUpdate 'None' -ErrorAction SilentlyContinue; Get-DnsServerZone -Name $ZoneName | Format-List ZoneName,ZoneType,IsDsIntegrated,DynamicUpdate,ZoneFile"

This creates a file-backed primary zone and prevents dynamic updates, reducing the risk of unauthorized record registration.

Add internal records that must never be exposed externally

Now we add internal records. We will add an internal application endpoint and an internal load balancer record. We will first define the IPs as variables so the commands remain clean and repeatable.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$ZoneName='corp.company.com'; $AppName='app'; $AppIP='10.50.10.25'; $LbName='lb'; $LbIP='10.50.10.10'; $ZoneName,$AppName,$AppIP,$LbName,$LbIP"

This defines the internal names and IPs we are about to publish in internal DNS.

Next, we create the A records.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$ZoneName='corp.company.com'; $AppName='app'; $AppIP='10.50.10.25'; $LbName='lb'; $LbIP='10.50.10.10'; Add-DnsServerResourceRecordA -ZoneName $ZoneName -Name $AppName -IPv4Address $AppIP -TimeToLive 01:00:00 -ErrorAction SilentlyContinue; Add-DnsServerResourceRecordA -ZoneName $ZoneName -Name $LbName -IPv4Address $LbIP -TimeToLive 01:00:00 -ErrorAction SilentlyContinue; Get-DnsServerResourceRecord -ZoneName $ZoneName | Where-Object { $_.HostName -in @($AppName,$LbName) } | Format-Table HostName,RecordType,TimeToLive,@{n='Data';e={$_.RecordData.IPv4Address}} -AutoSize"

This publishes internal-only endpoints with a reasonable TTL and then prints the records so we can confirm the exact data now served to internal clients.

We verify split-DNS behavior by querying the internal zone from the DNS server itself.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Resolve-DnsName -Name app.corp.company.com -Server 127.0.0.1 -Type A | Select-Object Name,Type,IPAddress | Format-Table -AutoSize"

This confirms the internal DNS server returns the internal IP for the internal name. Externally, this zone should not exist at all, or should return only what is intended for external users.

Split-DNS explained in operational terms

Here is the operational rule we enforce:

• Internal clients use internal DNS resolvers. They can resolve internal zones like corp.company.com and can also resolve external names through controlled forwarding.
• External clients never query internal DNS resolvers. They use external authoritative DNS for public zones, and they never see internal-only records.

Split-DNS is not a trick. It is a boundary. The boundary is enforced by network access controls, firewall rules, and recursion/query policies on the DNS servers.

Step 6: Enable DNS logging and auditing for incident response

When DNS is abused, the first question is always the same: “What did the client ask, and what did the server answer?” Without logs, we guess. With logs, we investigate.

On Windows Server DNS, we can enable DNS analytical and audit logs. These are high-volume in busy environments, so we should be intentional: enable them, forward them to a SIEM, and set retention appropriately.

First, we check the current DNS event log channels.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "wevtutil el | findstr /i dns"

This lists DNS-related event channels available on the server.

Now we enable the DNS Server Analytical and Audit logs. We do this to capture query activity and administrative changes. We should ensure we have a log forwarding strategy before enabling analytical logs in very high-throughput environments.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "wevtutil sl 'Microsoft-Windows-DNSServer/Analytical' /e:true; wevtutil sl 'Microsoft-Windows-DNSServer/Audit' /e:true; wevtutil gl 'Microsoft-Windows-DNSServer/Analytical'; wevtutil gl 'Microsoft-Windows-DNSServer/Audit'"

This enables both channels and prints their configuration so we can confirm they are active.

We verify that events are being written by querying recent entries. On a quiet server, we may need to generate a query first (for example, by running a Resolve-DnsName command) and then re-check.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-WinEvent -LogName 'Microsoft-Windows-DNSServer/Audit' -MaxEvents 20 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List"

This confirms the audit channel is producing readable events we can use during investigations.

Step 7: Firewall hardening for DNS service exposure

DNS uses UDP/53 for most queries and TCP/53 for zone transfers and large responses. In enterprise environments, we should allow DNS only from internal networks and only to the servers that must provide it.

First, we inspect existing DNS firewall rules so we understand what is already open.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-NetFirewallRule -DisplayGroup 'DNS Server' | Select-Object DisplayName,Enabled,Direction,Action,Profile | Format-Table -AutoSize"

This shows whether the built-in DNS Server firewall rules are enabled and which profiles they apply to.

Now we scope inbound DNS to internal subnets. We will create explicit allow rules for UDP/53 and TCP/53 from our internal ranges, and we will disable broad rules if they are too permissive. We will first define the internal ranges as a comma-separated string for firewall cmdlets.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$InternalRemoteAddrs = '10.0.0.0/8,172.16.0.0/12,192.168.0.0/16'; $InternalRemoteAddrs"

This prepares the remote address scope used by Windows Firewall rules.

Next, we add scoped inbound rules. We keep them explicit and named so they are easy to audit later.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "$InternalRemoteAddrs = '10.0.0.0/8,172.16.0.0/12,192.168.0.0/16'; New-NetFirewallRule -DisplayName 'DNS Inbound UDP 53 (Internal Only)' -Direction Inbound -Action Allow -Protocol UDP -LocalPort 53 -RemoteAddress $InternalRemoteAddrs -Profile Domain,Private -Program '%SystemRoot%System32dns.exe' -ErrorAction SilentlyContinue; New-NetFirewallRule -DisplayName 'DNS Inbound TCP 53 (Internal Only)' -Direction Inbound -Action Allow -Protocol TCP -LocalPort 53 -RemoteAddress $InternalRemoteAddrs -Profile Domain,Private -Program '%SystemRoot%System32dns.exe' -ErrorAction SilentlyContinue; Get-NetFirewallRule -DisplayName 'DNS Inbound UDP 53 (Internal Only)','DNS Inbound TCP 53 (Internal Only)' | Get-NetFirewallAddressFilter | Format-Table -AutoSize"

This creates two inbound rules limited to internal networks on Domain/Private profiles and confirms the remote address scoping. In production, we should ensure the server’s network profile is correct and that Public profile is not used for internal interfaces.

Step 8: Verification checklist after implementation

Now we validate behavior from three angles: service health, recursion control, and split-DNS correctness.

Service health

We confirm the DNS service is running and listening on port 53.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-Service DNS | Format-List Status,StartType; Get-NetTCPConnection -LocalPort 53 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess | Format-Table -AutoSize; Get-NetUDPEndpoint -LocalPort 53 | Select-Object LocalAddress,LocalPort,OwningProcess | Format-Table -AutoSize"

This confirms the service state and that the server is listening on TCP/53 and UDP/53.

Recursion control

We confirm recursion policies exist and are applied.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-DnsServerQueryResolutionPolicy | Sort-Object Name | Format-Table Name,Action,ApplyOnRecursion,ClientSubnet -AutoSize; Get-DnsServerRecursion | Format-List Enable,SecureResponse"

This confirms recursion is enabled but controlled by policy, and secure responses are enabled.

Split-DNS correctness

We confirm internal records resolve internally and that external resolution still works through forwarders.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Resolve-DnsName -Name app.corp.company.com -Server 127.0.0.1 -Type A | Select-Object Name,Type,IPAddress | Format-Table -AutoSize; Resolve-DnsName -Name example.com -Server 127.0.0.1 -Type A | Select-Object Name,Type,IPAddress | Format-Table -AutoSize"

This confirms internal zone resolution and external name resolution both work as designed, through the same controlled resolver.

Troubleshooting

Symptom: Internal clients cannot resolve any external names

• Likely causes:
  • Forwarders are unreachable (routing, ACLs, upstream down).
  • Firewall blocks outbound DNS from the DNS server to upstream resolvers.
  • Forwarders configured incorrectly.
• Fix:
  • Confirm forwarders are set and root hints fallback is disabled as intended.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-DnsServerForwarder | Format-Table -AutoSize; Test-NetConnection -ComputerName 10.20.30.40 -Port 53; Test-NetConnection -ComputerName 10.20.30.41 -Port 53"

This confirms forwarder configuration and tests TCP/53 reachability. If TCP works but UDP is blocked, name resolution may still fail; we should validate network policy for UDP/53 as well.

Symptom: Some clients resolve internal names, others do not

• Likely causes:
  • Clients are using different DNS servers (DHCP scope mismatch, static DNS settings).
  • Split-DNS zone exists on one DNS server but not replicated to others.
  • Conditional forwarders or policies differ between resolvers.
• Fix:
  • Confirm client DNS settings and confirm the zone exists on all internal resolvers.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-DnsServerZone | Select-Object ZoneName,IsDsIntegrated,ReplicationScope | Sort-Object ZoneName | Format-Table -AutoSize; ipconfig /all"

This confirms zone presence on the server and shows the local machine’s DNS client configuration for comparison.

Symptom: DNS server is being abused as a resolver from unexpected networks

• Likely causes:
  • Firewall rules allow inbound DNS from broad ranges.
  • Recursion policies are missing or mis-ordered.
  • Server is exposed on a perimeter interface.
• Fix:
  • Confirm inbound firewall scoping and confirm recursion policies are present.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-NetFirewallRule -DisplayName 'DNS Inbound UDP 53 (Internal Only)','DNS Inbound TCP 53 (Internal Only)' | Get-NetFirewallAddressFilter | Format-Table -AutoSize; Get-DnsServerQueryResolutionPolicy | Format-Table Name,Action,ApplyOnRecursion,ClientSubnet -AutoSize"

This validates that only internal networks can reach DNS and that recursion is denied for non-internal clients.

Symptom: Internal zone updates fail (dynamic registration not working)

• Likely causes:
  • Zone is set to None for dynamic updates (expected for non-AD zones).
  • Zone is AD-integrated but secure updates fail due to permissions or machine account issues.
  • Clients are not domain-joined or are registering to the wrong DNS server.
• Fix:
  • Confirm zone dynamic update settings and align them with the environment’s identity model.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-DnsServerZone -Name 'corp.company.com' | Format-List ZoneName,IsDsIntegrated,DynamicUpdate,ReplicationScope"

This confirms whether the zone is AD-integrated and whether secure updates are enabled.

Common mistakes

Mistake: Leaving root hints enabled while assuming forwarding is enforced

Symptom: DNS resolution still works even when upstream forwarders are blocked, and egress DNS traffic appears to unexpected destinations.

Fix: Disable root hint fallback for forwarders so resolution cannot silently bypass the intended path.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Set-DnsServerForwarder -UseRootHint $false; Get-DnsServerForwarder | Format-List UseRootHint,IPAddress"

This enforces forwarding-only behavior and confirms the setting.

Mistake: Broad firewall exposure of port 53

Symptom: Security monitoring flags the DNS server as an open resolver or sees queries from non-corporate IP ranges.

Fix: Scope inbound DNS rules to internal networks and ensure Public profile is not permitting DNS.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "Get-NetFirewallRule | Where-Object { $_.Enabled -eq 'True' -and $_.Direction -eq 'Inbound' } | Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 53 } | Format-Table -AutoSize"

This surfaces any enabled inbound rules that expose port 53 so we can remove or scope them appropriately.

Mistake: Split-DNS zone created internally but clients still use external resolvers

Symptom: Internal users resolve public answers for internal services, causing hairpinning, authentication failures, or latency spikes.

Fix: Ensure DHCP option 006 points to internal DNS resolvers only, and ensure VPN clients receive internal DNS settings.

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "ipconfig /all | findstr /i 'DNS Servers'"

This confirms which DNS servers the client is actually using. If it is not our internal resolver, split-DNS cannot work reliably.

How do we at NIILAA look at this

This setup is not impressive because it is complex. It is impressive because it is controlled. Every component is intentional. Every configuration has a reason. This is how infrastructure should scale — quietly, predictably, and without drama.

At NIILAA, we help organizations design DNS architectures that stay secure under growth: split-DNS boundaries that do not leak, resolver paths that are auditable, policies that survive real-world change, and operations that remain calm during incidents. We design, deploy, secure, and maintain these systems in production environments, aligning DNS with identity, network segmentation, and enterprise monitoring so it remains a strength instead of a hidden risk.

• Website: https://www.niilaa.com
• Email: [email protected]
• LinkedIn: https://www.linkedin.com/company/niilaa
• Facebook: https://www.facebook.com/niilaa.llc