https://imds.foo/tags/cross-tenant/Recent content in Cross-Tenant on imds.fooHugoen-usMon, 05 Oct 2026 19:36:38 +0200https://imds.foo/posts/cross-tenant-dns-policy/Wed, 02 Sep 2026 00:00:00 +0000https://imds.foo/posts/cross-tenant-dns-policy/<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-console" data-lang="console"><span class="line"><span class="cl"><span class="gp">#</span> before </span></span><span class="line"><span class="cl"><span class="gp">$</span> dig +short probe.lab.internal </span></span><span class="line"><span class="cl"><span class="go">192.0.2.53 </span></span></span><span class="line"><span class="cl"><span class="err"> </span></span></span><span class="line"><span class="cl"><span class="gp">#</span> after </span></span><span class="line"><span class="cl"><span class="gp">$</span> dig +short probe.lab.internal </span></span><span class="line"><span class="cl"><span class="go">blockpolicy.azuredns.invalid. </span></span></span></code></pre></div><p>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.</p> <p>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&rsquo;t want an attacker to decide which DNS queries get blocked. Logging is also not optimal.</p>