AI Assist Is it safe to share your unique DoH address?

[rashmi]

Refine the Firewall Rules (Re-Create if Needed): The originals might be blocking too much—let's make them precise.

• Delete the old rules (right-click > Delete) to start fresh.
• Create new Outbound Rule:
  • Rule Type: Port.
  • Protocol: UDP (do TCP separately if blocking that too).
  • Specific remote ports: 53 (important—use remote ports, not local, to block only outbound to DNS servers; local ports should be blank or "All").
  • Action: Block.
  • Profile: All.
  • Name: "Block Outbound UDP 53 (Remote)".
• For Inbound: Same but Specific remote ports: 53 (inbound typically uses local ports, but remote focus helps avoid blocking internal traffic).
• Key Fix: In the rule's "Scope" tab, ensure it applies to "Any IP address" for local, but you can exclude loopback (127.0.0.1) if local DNS is involved—though usually not needed.
• Enable the rules one by one and test with YogaDNS running.

I tested again, and the internet still doesn't work with or without YogaDNS; the websites can't find the DNS address. When I add an exception for 127.0.0.1, the internet works regardless of YogaDNS. For now, I'll leave it, as I'm satisfied with YogaDNS's reliability, but I may revisit this issue later.

 

[Bot]

I tested again, and the internet still doesn't work with or without YogaDNS; the websites can't find the DNS address. When I add an exception for 127.0.0.1, the internet works regardless of YogaDNS. For now, I'll leave it, as I'm satisfied with YogaDNS's reliability, but I may revisit this issue later.

Hey rashmi—thanks for the update and testing this out again; I totally get wanting to hit pause when it's close but not quite there, especially if YogaDNS is holding strong for your needs right now. It's frustrating when the firewall tweaks don't play nice, but your results actually give a clear clue on what's happening—let's break it down quickly based on how Windows DNS and YogaDNS work (per Microsoft and YogaDNS docs), then I'll respect your call to leave it and suggest a low-pressure path forward.

### What Your Tests Reveal
- No Internet With/Without YogaDNS (Rules Active, No Exception): This points to the block being too strict—it's likely catching local loopback traffic (127.0.0.1) that YogaDNS relies on to intercept and reroute queries internally. Without that, even encrypted DNS can't resolve, as the system can't "talk" to itself for redirection. Websites failing with "can't find DNS address" is a classic symptom of total DNS blockage.
- Internet Works With Exception (Regardless of YogaDNS): Adding the 127.0.0.1 exception allows loopback to function, so queries can flow locally. But without YogaDNS running, it means plain DNS (UDP 53) is slipping through to external servers—bypassing encryption and potentially leaking to your ISP's DPI/CGNAT. With YogaDNS on, it should enforce DoT/DoH, but the exception might weaken the overall leak protection (e.g., rogue apps could still try plain DNS externally if not fully intercepted).

In short: The exception gets you online but might not fully seal leaks, as it could allow some unencrypted outbound traffic on port 53 if YogaDNS misses anything. That's why refining the rules (as I suggested last time—focusing on remote ports and scope) is key for balance.

### Quick Refresher on Refining Those Rules (For When You Revisit)
If/when you dive back in, here's a tweaked version based on your loopback findings—aiming to block external plain DNS while allowing internal interception. (This builds on my previous steps; test with monitoring tools like TCP UDP Watch to confirm.)

1. Delete Old Rules: In Firewall Advanced, remove the existing ones to avoid conflicts.
2. New Outbound Rule for UDP 53:
   • Type: Port > UDP > Specific remote ports: 53 (leave local ports as "All").
   • Action: Block.
   • Scope: Local IP: Any; Remote IP: Any except 127.0.0.1 (add it as an exception here to protect loopback).
   • Profile: All > Name: "Block External UDP 53 (Loopback Excepted)".
3. Inbound (Optional): Same setup, but focus on remote ports.
4. Test Sequence: Enable rule > Restart YogaDNS service > Flush DNS (ipconfig /flushdns) > Try nslookup > Monitor for blocks on external IPs only.

This should let YogaDNS handle loopback without letting plain DNS escape externally. If it still breaks, disabling Dnscache (as we discussed) or switching to DoH in YogaDNS could help.

### Tying in the Router Angle (Optional Upgrade Path)
Like SeriousHoax mentioned with their Cudy/OpenWrt setup, shifting enforcement to the router could sidestep these client-side headaches entirely—blocking ports 53/853 at the network level and forcing DoH for all devices. If your router supports OpenWrt (check openwrt.org/toh), it's worth a look when you revisit; it'd make YogaDNS redundant for leaks and simplify everything. No rush, though—YogaDNS is reliable on its own for many folks.

Totally fair to leave it for now if it's working well enough; security setups are all about what fits your workflow without causing headaches. If you notice any leaks down the line (e.g., via dnsleaktest.com) or want to tweak further, just holler—happy to brainstorm more. What's your next focus, or any other quirks popping up?