Deploying DNS Private Resolvers and Private DNS Zones for Azure AI Supported Services
Private Networks: Private DNS Zones: Resolves domain names to private IPs within Azure virtual networks without exposing them to the internet. Private DNS Zones are global, you don’t need to create multiple same private DNS Zones, you can reuse the same zones as it’s global DNS Private Resolvers: Fully managed service that enables DNS resolution between Azure VNets and on-premises networks without custom DNS servers. DNS Private resolvers are regional, which means if you have Azure EAST US and WEST US 2 regions, you need to create DNS Private resolvers in both regions linked to Private DNS Zones, you can adopt centralized or distributed DNS Private resolvers, I will discuss both options later in this article Public Networks: <In this part – not focusing on Public Networks> Public DNS Zones: Resolves internet-facing domain names to publicly accessible IP addresses Traffic Managers: DNS-based traffic load balancer that routes client requests to the best available global endpoint DNS Security Policy: Controls and protects DNS resolution behavior (e.g., filtering, forwarding, and access rules) to secure name resolution and prevent misuse **Note: 1. Follow Prerequisites to deploy resources. 2. A common misconception is that VNet peering enables DNS resolution. In reality, private DNS zones are only accessible to VNets that are explicitly linked to them, peering provides connectivity, but not name resolution. In the following snapshot à Azure Portal à Network Foundations à DNS, lets explore individual DNS Services offered and later in this document, we will interconnect **Credits to Microsoft Azure Portal Design team for creating new grouped views – you can check out for more – like compute infrastructure, Hybrid, Backup Now, let’s delve into scenario 01: I have grabbed the following snapshot from Azure AI Landing Zones and removed non-network Azure resources to focus only on private Network components, **Credits to AI Landing Zone team for the diagram, Original Version: Inbound Zoom in view with End-to-End Flow Hop Summary 1 Client initiates request 2 DNS query sent to on-prem DNS 3 DNS query forwarded to Azure 4 Azure DNS Resolver processes query 5 Private DNS resolves to Private Endpoint IP 6 Traffic routed via VNet peering 7 Traffic hits Private Endpoint 8 Request served by Azure Files *Link Private DNS to DNS resolvers in other regions, Private DNS is GLOBAL and DNS Resolvers are regional Example Snapshot of entire flow: Nslookup from Client machine, Domain – DNS Conditional Forwarder configuration Note 1: Make sure you selected “All DNS Servers in this forest” for replication, otherwise users pointed to some other domain will be unable to resolve Verifying Connectivity with PsPing <credit to Sysinternals team PsPing > PsPing, a tool from Sysinternals, is highly effective for verifying network connectivity from on-premises environments to Azure resources on specific ports. This is particularly useful when you need to ensure connectivity to ports such as 445, 443, 1433, 1521, or any other port required by Azure services you intend to access from either on-premises locations or other cloud environments. By using PsPing, you can test and confirm that the necessary ports are open and accessible, which is crucial for troubleshooting connectivity issues and ensuring smooth communication between your on-premises infrastructure and Azure-hosted resources. Ensure your firewall is set to allow traffic DNS private resolvers – inbound configuration Private DNS Configuration Virtual Network links enable to your private dns Make sure you have peer between hub and spoke Private Endpoint configuration Storage Account configuration “Replace the file share with any supported Azure service that uses Private Endpoints, and follow the same guidance.” 2. Outbound <flow and resources colored with blue> part 2 upcoming soon
Connect to ERWIN Data Mart SaaS instance
Hello All Good morning As a part of our end-to-end data governance implementation, we are trying to setup Purview connectivity to ERWIN data mart which is setup as a SaaS instance. I had a look at documentation here and it is all specifying On Premise ERWIN implementation and setup of self hosted integration runtime etc. Can anyone please guide on how to proceed in cases where ERWIN mart is on cloud? Is this currently supported with the available ERWIN connector? Thanks in advance for any leads you may have. Regards Visakh
Security Considerations for SMTP Add-on Service Receiving Emails from Exchange Online
Hello everyone, I'm developing an email processing service for Microsoft 365 / Exchange Online customers. This service acts as an SMTP endpoint that receives all outbound emails from our customers' Exchange Online tenants via Outbound Connectors, processes them, and then relays the messages back to Exchange Online for final delivery. I found the https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/integrate-office-365-with-an-email-add-on-service page with suggestions. We're currently evaluating security risks and would like to clarify how much trust can be placed in messages coming from Exchange Online. Scenario Summary Our customers configure an Exchange Online Outbound Connector to route outbound emails to our service. We process these emails and then reinject them to Exchange Online, possibly via a smart host or authenticated SMTP relay. All emails received by our service originate from Exchange Online IP ranges, and our SMTP service is restricted to accept connections only from those IPs. Questions Can messages from Exchange Online IPs be spoofed? Given that all customers share Exchange Online's IP ranges, can an attacker: Forge the MAIL FROM envelope address? Spoof the From: header field? Impersonate another customer (tenant) using the shared infrastructure? What level of trust can we place in the envelope sender (MAIL FROM) and header From address? What security signals or headers should we rely on? Are there Exchange Online-specific SMTP headers or identifiers we can use to validate the authenticity and origin of the message? For example: Is the tenant ID or authenticated user available in the headers? Can we reliably identify the sending customer? What authentication or validation mechanisms are recommended? What are Microsoft's best practices for: Validating tenant identity for messages received via connector? Preventing cross-tenant spoofing, especially when IPs are shared? Verifying message integrity (e.g., should we re-verify DKIM, SPF?) Any other Microsoft-recommended protections? Thanks in advance to anyone from the Microsoft team or the community who can provide insights or suggestions!End-to-end TLS with AKS, Azure Front Door, Azure Private Link Service, and NGINX Ingress Controller
This article shows how Azure Front Door Premium can be set to use a Private Link Service to expose an AKS-hosted workload via NGINX Ingress Controller configured to use a private IP address on the internal load balancer.
