diff --git a/src/pentesting-web/cors-bypass.md b/src/pentesting-web/cors-bypass.md
index f304fad8928..0df060929e1 100644
--- a/src/pentesting-web/cors-bypass.md
+++ b/src/pentesting-web/cors-bypass.md
@@ -413,6 +413,36 @@ You can find more information about the previous bypass techniques and how to us
 
 [**`Singularity of Origin`**](https://github.com/nccgroup/singularity) is a tool to perform [DNS rebinding](https://en.wikipedia.org/wiki/DNS_rebinding) attacks. It includes the necessary components to rebind the IP address of the attack server DNS name to the target machine's IP address and to serve attack payloads to exploit vulnerable software on the target machine.
 
+### DNS Rebinding over DNS-over-HTTPS (DoH)
+
+DoH simply tunnels the classic RFC1035 DNS wire format inside HTTPS (usually a POST with `Content-Type: application/dns-message`). The resolver still answers with the same resource records, so SOP-breaking techniques continue to work even when browsers resolve the attacker-controlled hostname via TLS.
+
+#### Key observations
+
+- Chrome (Windows/macOS) and Firefox (Linux) successfully rebind when configured for Cloudflare, Google, or OpenDNS DoH resolvers. Transport encryption neither delays nor blocks the attack-flow for **first-then-second**, **multiple-answers**, or **DNS cache flooding** strategies.
+- Public resolvers still see every query, but they rarely enforce the host-to-IP mapping a browser must honor. Once the authoritative server returns the rebinding sequence, the browser keeps the original origin tuple while connecting to the new IP.
+
+#### Singularity strategies and timing over DoH
+
+- **First-then-second** remains the most reliable option: the first lookup returns the attacker IP that serves the payload, every later lookup returns the internal/localhost IP. With typical browser DNS caches this flips traffic in ~40–60 seconds, even when the recursive resolver is only reachable over HTTPS.
+- **Multiple answers (fast rebinding)** still reaches localhost in <3 seconds by answering with two A records (attacker IP + `0.0.0.0` on Linux/macOS or `127.0.0.1` on Windows) and programmatically blackholing the first IP (for example, `iptables -I OUTPUT -d <attacker_ip> -j DROP`) shortly after the page loads. Firefox’s DoH implementation may emit repeated DNS queries, so the Singularity fix is to schedule the firewall rule relative to the **first** query timestamp instead of refreshing the timer on every query.
+
+#### Beating “rebind protection” in DoH providers
+
+- Some providers (e.g., NextDNS) replace private/loopback answers with `0.0.0.0`, but Linux and macOS happily route that destination to local services. Intentionally returning `0.0.0.0` as the second record therefore still pivots the origin to localhost.
+- Filtering only the direct A/AAAA response is ineffective: returning a **CNAME** to an internal-only hostname makes the public DoH resolver forward the alias while browsers such as Firefox fall back to the system DNS for the internal zone, completing the resolution to a private IP that is still treated as the attacker origin.
+
+#### Browser-specific DoH behavior
+
+- **Firefox DoH** operates in fallback mode: any DoH failure (including an unresolved CNAME target) triggers a plaintext lookup via the OS resolver, which is typically an enterprise DNS server that knows the internal namespace. This behavior is what makes the CNAME bypass reliable inside corporate networks.
+- **Chrome DoH** only activates when the OS DNS points to a whitelisted DoH-capable recursive resolver (Cloudflare, Google, Quad9, etc.) and does not provide the same fallback chain. Internal hostnames that only exist on corporate DNS therefore fail to resolve, but rebinding toward localhost or any routable address still succeeds because the attacker controls the entire response set.
+
+#### Testing and monitoring DoH flows
+
+- Firefox: `Settings ➜ Network Settings ➜ Enable DNS over HTTPS` and provide the DoH endpoint (Cloudflare and NextDNS are built in). Chrome/Chromium: enable `chrome://flags/#dns-over-https` and configure the OS DNS servers to one of Chrome’s supported resolvers (e.g., `1.1.1.1`/`1.0.0.1`).
+- You can query public DoH APIs directly, e.g. `curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq` to confirm the exact records browsers will cache.
+- Intercepting DoH in Burp/ZAP still works because it is just HTTPS (binary DNS payload in the body). For packet-level inspection, export TLS keys (`export SSLKEYLOGFILE=~/SSLKEYLOGFILE.txt`) before launching the browser and let Wireshark decrypt the DoH sessions with the `dns` display filter to see when the browser stays on DoH or falls back to classic DNS.
+
 ### Real Protection against DNS Rebinding
 
 - Use TLS in internal services
@@ -442,6 +472,7 @@ You can find more information about the previous bypass techniques and how to us
 - [https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646](https://medium.com/netscape/hacking-it-out-when-cors-wont-let-you-be-great-35f6206cc646)
 - [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/CORS%20Misconfiguration)
 - [https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b](https://medium.com/entersoftsecurity/every-bug-bounty-hunter-should-know-the-evil-smile-of-the-jsonp-over-the-browsers-same-origin-438af3a0ac3b)
+- [NCC Group - Impact of DNS over HTTPS (DoH) on DNS Rebinding Attacks](https://www.nccgroup.com/research-blog/impact-of-dns-over-https-doh-on-dns-rebinding-attacks/)
 
 
 {{#include ../banners/hacktricks-training.md}}