Share via

Getting NXDOMAIN to database.windows.net through Azure Firewall DNS Proxy.

Kjell Bulcke 20 Reputation points
2026-04-03T15:08:45.81+00:00

Hello everyone.

As of last night we started getting reports of DNS no longer correctly resolving against *.database.windows.net
The setup was working for over 3 months thus far.

This is a cloud-only environment.
2 tenants connected through Azure VPN Gateway S2S.
Container apps in tenantA go to multiple databases in TenantB.

Services:
Azure Firewall Standard with DNS enabled policy that has DNS server set to custom = 168.63.129.16 and has proxy enabled.

There are no (private) dns zones or resolvers that can interfere with this. Hence it was working fine for quite a few months.

We have resolved everything by placing multiple private dns zones so it resolves correctly to the specific databases with a private endpoint as it should have been configured anyway.

Anybody any ideas or insights on why we suddenly would be getting NXDOMAINS?

Azure Firewall
Azure Firewall

An Azure network security service that is used to protect Azure Virtual Network resources.

0 comments
Answer accepted by question author
  1. Q&A Assist
    2026-04-03T15:09:00.79+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The most likely cause of sudden NXDOMAIN responses for *.database.windows.net through Azure Firewall DNS Proxy is a change in how/where those queries were being forwarded or resolved, not the firewall proxy itself.

    From the provided information, the key points are:

    • Azure Firewall DNS Proxy was configured with a custom DNS server = 168.63.129.16.
    • 168.63.129.16 is the Azure-provided DNS recursive resolver for the VNet where the firewall is deployed.
    • There were no Private DNS zones initially, so resolution for *.database.windows.net depended entirely on Azure public DNS via 168.63.129.16.

    Relevant behaviors from the documentation:

    1. Azure Firewall DNS Proxy simply forwards queries to its configured upstream DNS server and does not merge or alter results beyond caching.
      • If the upstream resolver (here, 168.63.129.16 or anything it forwards to) returns NXDOMAIN, the firewall will cache and return NXDOMAIN to clients.
      • The firewall does not “fix” or override upstream NXDOMAIN responses.
    2. For private endpoints, Microsoft recommends using a Private DNS zone such as privatelink.database.windows.net, and conditional forwarding must be configured to the public zone (database.windows.net) when using custom DNS.
      • If any change occurred in the path of DNS resolution (for example, conditional forwarders, custom DNS in another VNet, or hybrid forwarding via VPN) that incorrectly forwarded database.windows.net queries somewhere that does not know that zone, NXDOMAIN would result.
    3. In hybrid or multi-VNet setups, DNS resolution is sensitive to where the query originates and which resolver is used:
      • Queries must originate from the VNet linked to the relevant Private DNS zone for private endpoints.
      • If a DNS forwarder or resolver in another VNet or on-premises was introduced or changed (for example, via VPN, Private Resolver, or custom DNS), and that resolver did not correctly forward database.windows.net to Azure DNS, NXDOMAIN would appear suddenly even though the firewall configuration itself did not change.

    Given that the issue was fully resolved by:

    • Creating the appropriate Private DNS zones for the SQL private endpoints, and
    • Ensuring queries originate from the VNet linked to those zones,

    the root cause was almost certainly that database.windows.net queries were no longer being correctly resolved by the upstream DNS path (for example, due to a change in forwarding, resolver behavior, or service-side DNS behavior for private endpoints), and Azure Firewall DNS Proxy simply propagated those NXDOMAIN responses.

    The final configuration (private endpoints + Private DNS zones) aligns with the documented, supported pattern for SQL private endpoints and is the recommended long-term fix.

    References:

    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Ganesh Patapati 11,755 Reputation points Microsoft External Staff Moderator
    2026-04-07T15:43:40.0033333+00:00

    Hello Kjell Bulcke

    sounds like your Azure Firewall DNS proxy is caching an NXDOMAIN for *.database.windows.net once the record’s TTL expired—and without a Private DNS zone in your VNets, 168.63.129.16 won’t know about your database private endpoints, so it simply returns “no such domain.” Here’s what’s likely going on and how to fix it:

    1. Private Endpoint + DNS
    • When you created private endpoints in Tenant B for your SQL databases, Azure stopped serving the public A-records for <yourserver>.database.windows.net and expects you to host a Private DNS zone (database.windows.net) that contains the PE’s private IP.
    • If you never set up that Private DNS zone (or never linked it into Tenant A’s VNet), once the public record TTL expired, Azure DNS returns NXDOMAIN and your firewall caches it.
    1. Azure Firewall DNS Proxy Behavior
    • Firewall simply forwards queries to the upstream (168.63.129.16) and caches both positive and negative responses.
    • Negative cache TTL is up to 30 minutes—so once it gets NXDOMAIN, everything behind the firewall will see it until the negative cache expires (and there’s no prefetch).
    1. Client vs. Firewall Resolution
      • If your VMs/containers aren’t pointing at the firewall for DNS, they might get a different answer than the firewall itself—leading to confusing intermittent successes/failures.

    What you can do:

    • Create a Private DNS zone “database.windows.net” in Tenant B (or a central DNS subscription) and link it into both VNets so that any query for <dbserver>.database.windows.net resolves to the PE’s private IP.
    • Make sure your VNets’ DNS server setting is the firewall private IP, and DNS proxy on the firewall is enabled.
    • Flush the firewall’s DNS cache (toggle DNS proxy off/on or redeploy the policy) so it picks up the new zone.
    • Test with nslookup Command <your-db>.database.windows.net <firewall-IP> to confirm you get the PE’s IP and not NXDOMAIN.

    Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

    If these answer your question, click "Upvote" and click "Accept Answer" which may be beneficial to other community members reading this thread.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.