[Bug Report] Conflicting/confusing IPs when resolving a domain name

[tredondo]

Describe the bug:

When intercepting a DNS request, the GUI shows different values for the Destination IP in the normal vs. advanced view. For example when running wget foo.org, the normal view shows 127.0.0.53 (my DNS server is 192.168.8.1 according to resolvectl, but dig does connect to 127.0.0.53):

While the advanced view shows foo.org as the IP (it's not an IP):

Include the following information:

• OpenSnitch version: 1.7.0.0
• OS: Ubuntu 25.04
• Window Manager: KDE 6
• Kernel version: Linux 6.14.0-15-generic #15-Ubuntu SMP PREEMPT_DYNAMIC Sun Apr 6 15:05:05 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (wlo1)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.8.1
       DNS Servers: 192.168.8.1
        DNS Domain: lan
     Default Route: yes

$ dig google.com
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out

Expected behavior (optional):

A clearer indication of what exactly would be denied or allowed: connecting to 127.0.0.53? Resolving that specific domain?

Another element of confusion is that if you click the Destination IP drop-down, foo.org is not preceded by "to", while the other IPs (and LAN) are:

UPDATE

Turns out I was wrong in both my expectations of what would be allowed or denied. I clicked Allow and the rule that was created seems to allow everything from wget:

I think this resulting rule is technically correct, but not what I intended.

Suggestion: what if when switching to the Advanced view, or if the Advanced view is the default, the "Destination IP" checkbox was checked?