Creating parent reverse lookup zone when child zones already exist — what happens?
We have an AD-integrated DNS environment that has accumulated a large number of reverse lookup zones over time, created without any parent zone — essentially DNS sprawl from years of admins creating individual subnet zones rather than working from a parent. We currently have approximately 80+ reverse lookup zones including: Dozens of x.10.in-addr.arpa zones covering various 10.x.x.x subnets Multiple x.172.in-addr.arpa zones A handful of others including 100.192.10.in-addr.arpa, 168.192.in-addr.arpa, 204.167.in-addr.arpa, 215.204.167.in-addr.arpa, 135.7.in-addr.arpa None of these were ever delegated from a parent zone — they were just created independently. The 10.in-addr.arpa zone does not exist. Domain controllers are a mix of Windows Server 2019 Standard (majority) and Windows Server 2025 Standard. Our goal is to create 10.in-addr.arpa as the consolidation point going forward — new registrations go there, and we migrate existing child zones into it one at a time, deleting old ones as we go at a pace we're comfortable with. Before touching anything, we need to understand what creating 10.in-addr.arpa will actually do to the existing child zones. Specifically: Will existing records in the child zones be deleted? We've seen the TechNet article documenting records vanishing when creating a child zone under an existing parent — does the same destructive behaviour occur in the reverse direction? Will auto-delegations be created in the new parent zone pointing to the existing child zones, and if so how quickly? Will the child zones continue to function normally for queries while the parent exists alongside them? Will dynamic registration start hitting the parent zone for subnets not covered by an existing child zone, or will something unexpected happen? We can't test this in a lab as we don't have a replica environment available, and can't risk touching production without understanding the behaviour first. Pointers to any documentation covering this specific scenario would also be appreciated — we've been unable to find anything that addresses creating the parent after the children already exist independently.Connect to Azure SQL Database using a custom domain name with Microsoft Entra ID authentication
Many of us might prefer to connect to Azure SQL Server using a custom domain name (like devsqlserver.mycompany.com) rather than the default fully qualified domain name (devsqlserver.database.windows.net), often because of application-specific or compliance reasons. This article details how you can accomplish this when logging in with Microsoft Entra ID (for example, user@mycompany.com) in Azure SQL Database specific environment. Frequently, users encounter errors similar to the one described below during this process. Before you start: If you use SQL authentication (SQL username/password), the steps are different. Refer the following article for that scenario: How to use different domain name to connect to Azure SQL DB Server | Microsoft Community Hub With SQL authentication, you can include the server name in the login (for example, username@servername). With Microsoft Entra ID authentication, you don’t do that—so your custom DNS name must follow one important rule. Key requirement for Microsoft Entra ID authentication In an Azure SQL Database (PaaS) environment, the platform relies on the server name portion of the Fully Qualified Domain Name (FQDN) to correctly route incoming connection requests to the appropriate logical server. When you use a custom DNS name, it is important that the name starts with the exact Azure SQL server name (the part before .database.windows.net). Why this is required: Azure SQL Database is a multi-tenant PaaS service, where multiple logical servers are hosted behind shared infrastructure. During the connection process (especially with Microsoft Entra ID authentication), Azure SQL uses the server name extracted from the FQDN to: Identify the correct logical server Route the connection internally within the platform Validate the authentication context This behavior aligns with how Azure SQL endpoints are designed and resolved within Microsoft’s managed infrastructure. If your custom DNS name doesn’t start with the Azure SQL server name, Azure can’t route the connection to the correct server. Sign-in may fail and you might see error 40532 (as shown above). To fix this, change the custom DNS name so it starts with your Azure SQL server name. Example: if your server is devsqlserver.database.windows.net, your custom name must start with 'devsqlserver' devsqlserver.mycompany.com devsqlserver.contoso.com devsqlserver.mydomain.com Step-by-step: set up and connect Pick the custom name. It must start with your server name. Example: use devsqlserver.mycompany.com (not othername.mycompany.com). Create DNS records for the custom name. Create a CNAME or DNS alias to point the custom name to your Azure SQL server endpoint (public) or to the private endpoint IP (private) as per the blog mentioned above. Check DNS from your computer. Make sure devsqlserver.mycompany.com resolves to the right address before you try to connect. Connect with Microsoft Entra ID. In SSMS/Azure Data Studio, set Server to your custom server name and select a Microsoft Entra ID authentication option (for example, Universal with MFA). Sign in and connect. Use your Entra ID (for example, user@mycompany.com). Example: Also, when you connect to Azure SQL Database using a custom domain name, you might see the following error: “The target principal name is incorrect” Example: This happens because Azure SQL’s SSL/TLS certificate is issued for the default server name (for example, servername.database.windows.net), not for your custom DNS name. During the secure connection process, the client validates that the server name you are connecting to matches the name in the certificate. Since the custom domain does not match the certificate, this validation fails, resulting in the error. This is expected behavior and is part of standard security checks to prevent connecting to an untrusted or impersonated server. To proceed with the connection, you can configure the client to trust the server certificate by: Setting Trust Server Certificate = True in the client settings, or Adding TrustServerCertificate=True in the connection string This bypasses the strict name validation and allows the connection to succeed. Note: Please use the latest client drivers (ODBC/JDBC/.NET, etc.). In some old driver versions, the 'TrustServerCertificate' setting may not work properly, and you may still face connection issues with the same 'target principal name is incorrect' error. So, it is always better to keep drivers updated for smooth connectivity with Azure SQL. Applies to both public and private endpoints: This naming requirement and approach work whether you connect over the public endpoint or through a private endpoint for Azure SQL Database scenario, as long as DNS resolution for the custom name is set up correctly for your network.
DNS DOH and DOT Server 2025
Does anyone know if Windows Server 2025 is planning to support native DNS over HTTPS or DNS over TLS? As of now, windows clients can be configured to support this, but MS DNS is not DOH or DOT compliant. I am just wondering if this is being considered or if it is on the roadmap. Thanks!Lots of DNS Server events 5504 on AD DNS server from Cloudflare etc
Hi! I'm getting about 18 events with id 5504 while trying to resolve some DNS names, like fullfiles.xyz. The DNS server is configured to use provider DNS and root hints. I can suppress these messages by disabling root hints or by disabling EDNS0 with dnscmd /config /enablednsprobes 0. I tried to use packet capture on the DC and on the router, and analyzed the results with AI, which answered: "You receive malformed patterns on the WAN interface." Can anybody explain the cause of this problem? Any ideas to fix it? Thanks!Zero Trust DNS is Here: Elevating Enterprise Security on Windows 11
When attackers target an enterprise today, they rarely begin with a blunt smash-through-the-front-door intrusion. They begin quietly by resolving a domain. In most cases, modern malware, phishing kits, and human-operated ransomware operators rely on DNS as the entry point to discover infrastructure, beacon command-and-control, and exfiltrate data. Thus, it is becoming even more important to secure DNS to help protect against increasingly frequent, complex, and expensive cyberattacks. Enterprises have invested heavily in Protective DNS services with cutting-edge threat intelligence to identify and block malicious domains in real time but if an endpoint device can simply bypass them, the entire Zero Trust posture is weakened. Today, Microsoft is closing that gap. Introducing Zero Trust DNS (ZTDNS) We are excited to announce that Zero Trust DNS (ZTDNS) is now generally available on Windows 11 Enterprise and Windows 11 Education editions. ZTDNS is a new enterprise security feature in Windows that helps ensure DNS policy configured on the enterprise DNS server is enforced on the device. This is an important advancement for organizations working to enable that outbound connectivity on managed Windows devices aligns with enterprise authorization and policy. ZTDNS provides device-level enforcement of an enterprise’s DNS policy, in-box on Windows 11 helping ensure devices only communicate with destinations the organization intends. It doesn’t require installing and managing additional agents or maintaining a “best effort” block list on each endpoint device. With ZTDNS, the enterprise DNS resolver becomes the policy source of truth and Windows becomes the enforcement point. For more information, check out our documentation. This can be particularly useful for organizations in highly regulated industries, or where compliance with NIST standards is of paramount importance. Without ZTDNS, the system DNS client could be pointed to a network-provided malicious DNS server, which can resolve unapproved domains and return incorrect resolutions to redirect the system to attacker’s endpoint. If the malicious DNS server uses encrypted DNS, IT administrators won’t be able to analyze the DNS traffic to prevent or mitigate potential attacks. Applications can use their own DNS client to completely bypass system policies. Also, system remains vulnerable to in-network attackers. ZTDNS protects against these attack vectors by mandating the use of Windows DNS client and only sending encrypted DNS queries to the trusted DNS servers. Since ZTDNS blocks all outbound connections and local name resolution by default, the system is protected against in-network threats. Why is ZTDNS needed? In enterprise scenarios, DNS is no longer just a lookup mechanism but a policy decision point. However, without device-level enforcement, attackers can hijack device DNS to: Redirect DNS queries from the device to a malicious or compromised DNS server Use their own encrypted DNS client and bypass system DNS client Bypass DNS completely with direct IP connections In such cases, organizations lose the ability to control which network destinations the endpoint is allowed to reach even if a Protective DNS service is used. ZTDNS addresses this by only allowing outbound connections to IP addresses that were resolved by the trusted DNS server for a query issued by the Windows DNS client. More importantly, it achieves this without terminating end-to-end encryption. How does ZTDNS work? ZTDNS integrates the Windows DNS client with the Windows Filtering Platform to help enforce domain-name-based network lockdown using encrypted DNS. ZTDNS is off by default and can be configured on a Windows 11 device with an enterprise-approved DNS over HTTPS (DoH) or DNS over TLS (DoT) server. When enabled, ZTDNS blocks all outbound IP-based connections by default and only allows outbound connections to IP addresses resolved by the trusted DNS server or those added to the manual exception list by the IT administrator. It mandates the use of encrypted DNS (DoH or DoT) and only trusts the DNS resolutions initiated by the Windows DNS client and answered by the trusted DNS server to create outbound allow exceptions. This helps provide a strong, enforceable control that aligns with Zero Trust principles: all destinations are untrusted by default unless specifically permitted. In a nutshell, when configured and enabled, ZTDNS will have the following effects on your Windows 11 device: Encrypted DNS enforcement (DoH or DoT) Default deny for outbound IPv4 and IPv6 traffic Dynamic allow listing of IP addresses returned by trusted DNS servers Static allow listing of IP addresses approved by the IT administrator via manual exceptions Centralized logging of permitted and blocked connections Deploying ZTDNS ZTDNS is available in the latest builds of Windows 11 Enterprise and Windows 11 Education. To deploy ZTDNS, enterprises can configure and enable it via: netsh commands JSON configuration We are also actively developing a Microsoft Intune experience for ZTDNS and we will share more information when the details are available. For detailed deployment guidance, check out our official documentation. Connect with us For customers attending Microsoft Ignite 2025, please join us at session BRK258: Inside Windows Security, from client to cloud to learn more about ZTDNS. Alternatively, you can also visit the Windows Resiliency Initiative & Windows Security booth to discuss ZTDNS in depth. For customers who are unable to attend Microsoft Ignite 2025, we would still welcome the opportunity to connect. If you have questions about Zero Trust DNS, deployment considerations, or would like to share feedback from your evaluation, please contact us at ztdnsteam@microsoft.com. Securing the Present, Innovating for the Future Security is a shared responsibility. Through collaboration across hardware and software ecosystems, we can build more resilient systems secure by design and by default, from Windows to the cloud, enabling trust at every layer of the digital experience. The updated Windows Security book is available to help you understand how to stay secure with Windows. Learn more about Windows 11 and Copilot+ PCs. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
Edge now crashes bind due to it doing TCP DNS in the clear
Not sure if there is a option to turn this off on Edge as I have not looked. So all was fine with my setup I have BIND9.16.50 I have Acrylic DNS Proxy to send DNS to the bind server then the bind kept crashing and it seem Edge is now doing DNS by TCP in the clear if it can resulting Acrylic DNS Proxy to do DNS by TCP to bind I don't know why Microsoft has done this anyone know? After some testing to stop BIND from crashing you need to increase a added option for “tcp-clients” I set to 1000 the default was 150Announcing Public Preview of Zero Trust DNS
In today's evolving cybersecurity landscape, traditional perimeter defenses are no longer sufficient . As organizations embrace the Zero Trust security model, ensuring that devices only communicate with trusted network destinations becomes paramount. We are excited to announce the public preview of Zero Trust DNS (ZTDNS), a new feature in Windows 11 Insider builds designed to enforce domain-name-based network access controls, enhancing your organization's security posture. ZTDNS empowers enterprise IT administrators to natively apply outbound domain-name-based network access controls on Windows 11 endpoints. This helps prevent access to untrusted destinations, reducing the risk of a slew of network attacks from malware communication to data exfiltration. What is Zero Trust DNS? ZTDNS integrates the Windows DNS client with trusted Protective DNS (PDNS) servers to control outbound IP traffic based on domain names. When ZTDNS is configured on a Windows 11 device to use PDNS servers that support DNS over HTTPS (DoH) or DNS over TLS (DoT), ZTDNS ensures that: The Windows DNS client forces the use of encrypted DNS and queries are only sent to the configured PDNS servers. Outbound traffic is permitted only to IP addresses resolved by these trusted PDNS servers or to IP ranges with a manual exception plumbed by the IT administrator. All other IPv4 and IPv6 outbound traffic is blocked by default, adhering to the "deny by default" principle of Zero Trust. A log of attempted outbound connections is maintained on the device. This approach reduces the need for deep packet inspection or reliance on insecure signals like plain-text DNS or Server Name Indication (SNI) when attempting to determine the domain name associated with outbound traffic. This makes ZTDNS an important tool in the Zero Trust toolbelt since DNS traffic and SNI are increasingly being encrypted. It also aligns with Zero Trust principles by assuming all destinations are untrusted by default, only allowing connections to destinations explicitly permitted through DNS resolutions provided by trusted PDNS servers. For more information, visit our previous blog post on design of ZTDNS. Threats Zero Trust DNS Helps Mitigate Implementing ZTDNS can bolster your defenses against various network-based threats, including: DNS Hijacking: By ensuring that only DNS resolutions from trusted PDNS servers are used, ZTDNS helps prevent attackers from redirecting traffic to malicious sites. Malicious Communications: Blocking outbound connections to IP addresses not resolved through trusted DNS queries helps disrupt phishing and even non-administrative malware stagers and beacons. Data Exfiltration: Restricting outbound traffic to approved domains reduces the risk of sensitive data being transmitted to unauthorized destinations without conducting analysis of domain name resolution patterns. Getting Started with Zero Trust DNS NOTE: Public Preview of ZTDNS has officially ended. The instructions below are no longer supported. We appreciate you taking the time to test out ZTDNS in Public Preview. Your valuable feedback has helped us improve ZTDNS. For further assistance, please reach out to ztdnspreview@microsoft.com. To enable ZTDNS in your environment: Get a supported Windows 11 build Enroll your device in the Windows Insider Program (Canary channel) and update to build 27766+. Unlock ZTDNS In an administrator command prompt, run: reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" /v Experiment4712 /d 0xbe8261eb /t REG_DWORD Reboot the device. Ensure all applications and services are configured to use the Windows DNS client Configure applications like Edge and Chrome to use the Windows DNS client instead of their custom client (disable BuiltInDnsClientEnabled policy). Add manual allow exceptions Teleconferencing applications like Teams use WebRTC which negotiates IP addresses for peers within a TLS tunnel and has no DNS visibility. These IP subnets are also publicly documented and need manual allow exceptions for the application to work with ZTDNS. Add manual allow exceptions for IP addresses that are necessary for your productivity applications/services but are not discovered through DNS. Here is a sample command, for manual allow exception, which needs to run in administrator command prompt: netsh ztdns add exception name=AppName description="Description of AppName" subnets=192.0.2.128/25,198.51.100.0/24,3fff::/48, 3fff:123::/38 Here is a link Microsoft 365 services that may need manual allow exceptions. Set your trusted Protective DNS server (needs to be DoH/ DoT capable) In an administrator command prompt, replace example data in following sample commands with information about your desired DNS server before running: netsh ztdns add server type=doh address=203.0.113.0 template=https://doh.resolver.example/dns-query netsh ztdns add server type=dot address=2001:db8::1 hostname=dot.resolver.example Enable ZTDNS ZTDNS can be enabled using Audit mode or Enforcement mode. Audit mode logs all expected ZTDNS behavior without the actual enforcement. Check out the next blog post for finding and comprehending ZTDNS logs. Enabling ZTDNS in audit mode is recommended before moving on to Enforcement mode. In an administrator command prompt, run: netsh ztdns set state enable=yes audit=yes Enforcement mode blocks untrusted traffic. In an administrator command prompt, run: netsh ztdns set state enable=yes audit=no Now you should have ZTDNS running! In a rare situation where you experience unexpected connectivity issues for some application, please restart the application. If the issue persists, please reboot the device. Disable ZTDNS ZTDNS is a powerful lockdown feature. In case you lose network connectivity due to misconfiguration, you can disable ZTDNS to restore your network connectivity. In an administrator command prompt, run: netsh ztdns set state enable=no audit=no Note: ZTDNS is currently in Public Preview and is intended for evaluation and feedback only. Do not deploy in production environments. Breaking changes may occur before General Availability (GA). Check out the next blog post Troubleshooting Zero Trust DNS for information on ZTDNS logs, sharing feedback and bug reports with the team. Join Me at RSAC 2025 I am excited to share that I will be attending the RSA Conference 2025! If you are planning to be there, stop by Microsoft booth N-5744 or Microsoft Security Hub and ask for Aditi Patange to discuss how ZTDNS can enhance your organization's security posture. Securing the Present, Innovating for the Future Security is a shared responsibility. Through collaboration across hardware and software ecosystems, we can build more resilient systems secure by design and by default, from Windows to the cloud, enabling trust at every layer of the digital experience. The updated Windows Security book is available to help you understand how to stay secure with Windows. Learn more about Windows 11 and Copilot+ PCs. To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
Issue with DnsConnectorDelivery
Background: We are currently migrating from Exchange 2016 to 2019 in a hybrid environment. We have 2 2016 servers both in our main datacenter, and 2 2019 servers, one in our main datacenter and one in our offsite datacenter. Backup datacenter has its own DCs that are replicas of our main datacenter's DCs. Exchange 2019 has been installed and updated to CU 11. Problem: When I run the hybrid configuration wizard and select all 4 servers to be included in the send and receive connectors, everything completes and no errors appear. However, mail gets stuck in the DnsConnectorDelivery queue on the server in our backup datacenter. The NextHopDomain for the stuck mail is our M365 domain, domain.mail.onmicrosoft.com As soon as I remove the server in the backup site from the send and receive connectors, mail flows correctly again. I've done a lot of internet searching and it seems the issue has something to do with our MX record, but both domains have the correct record in their DNS. What could be causing the issue? Any help is appreciated!
