Dns on imds.foo

Cross-tenant DNS forwarding in Azure: plumbing that should not work?

Wed, 02 Sep 2026 00:00:00 +0000

My last post on cross-tenant DNS zones naturally leads to the question if other Azure DNS resources have the same visibility issue. One resource of great interest: Private DNS resolvers. DNS resolvers are basically the DNS plumbing Azure provides. You deploy a private one if you have inbound or outbound DNS queries requiring a more complex setup. For example from your on-premise datacenter to an IP in a delegated inbound endpoint subnet, which allows your on-prem infrastructure to resolve names in your Azure private zones. Outbound endpoints in combination with a resource called forwarding ruleset allow you to send Azure DNS queries to on-prem or 3rd party DNS servers. Forwarding rulesets basically define which queries get sent where.

When a foreign Private DNS zone answers inside your VNet

Wed, 02 Sep 2026 00:00:00 +0000

three months later

A developer working on Azure gets compromised via AitM phishing. You catch it: the sign-in is anomalous, the session gets revoked, all credentials are rotated, the device is reimaged. You enumerate what their identity can reach, you look for malicious activity and find that the attacker acted similar to you, they also enumerated permissions and looked up the infrastructure the developer was working on. But only that, no write operations. You close the ticket and move on to the next. Infostealer, boring.

Your DNS policy? My DNS Policy

Wed, 02 Sep 2026 00:00:00 +0000

# before
$ dig +short probe.lab.internal
192.0.2.53

# after
$ dig +short probe.lab.internal
blockpolicy.azuredns.invalid.

Nothing changed inside the VNet. No NSG, no route table, no resolver, no VM configuration. The object that changed the answer lives in a different Entra tenant, and the subscription owning the VNet logged no link operation for it. Because it cannot by design.

This is the third part of the Azure DNS ecosystem I have put through the same test: a child resource created in tenant B that references a VNet in tenant A. A private DNS zone, you can compare it with an address book: The attack worked, no way to detec. A forwarding ruleset, you can compare it with a pipeline that determines how requests flow: Attack worked, only way to detect it is in the DNSQueryLogs if an attacker starts to manipulate the DNS flow. A DNS resolver policy, a DNS security policy, sits in front of our pipeline. It watches queries, logs and decide which queries to block. And you don’t want an attacker to decide which DNS queries get blocked. Logging is also not optimal.