daeuniverse / dae

eBPF-based Linux high-performance transparent proxy solution.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Bug Report] Capturing an incorrect DNS qname

douglarek opened this issue · comments

Checks

  • I have searched the existing issues
  • I have read the documentation
  • Is it your first time sumbitting an issue

Current Behavior

dns settings:

dns {
    upstream {


        alidns: 'udp://dns.alidns.com:53'
        googledns: 'tcp+udp://dns.google.com:53'
    }
    routing {
        request {
            qname(suffix: api.miwifi.com) -> reject
            qname(geosite:cn) -> alidns
            qname(geosite:microsoft@cn) -> alidns
            # fallback is also called default.
            fallback: googledns
        }
    }
}

When I request api.miwifi.com and check the DAE log, it seems that there is an issue with the _qname during DNS resolution, causing DNS requests that should have been rejected to be resolved through the fallback DNS server.

dae log:

level=info msg="192.168.1.109:38729 <-> [2001:4860:4860::8888]:53" _qname=api.miwifi.com.lan. dialer="sg" dscp=0 mac="a0:e7:xx:xx:1f:8f" network="tcp6(DNS)" outbound=sg pid=0 pname= policy=min_moving_avg qtype=A
level=info msg="192.168.1.109:38729 <-> [2001:4860:4860::8888]:53" _qname=api.miwifi.com.lan. dialer="sg" dscp=0 mac="a0:e7:xx:xx:1f:8f" network="tcp6(DNS)" outbound=sg pid=0 pname= policy=min_moving_avg qtype=AAAA

Expected Behavior

It seems that it shouldn't be DNS resolved, or at least it shouldn't be resolved through the proxy.

Steps to Reproduce

You can simply use the DNS configuration mentioned above.

Environment

  • Dae version (use dae --version):
dae version 0.5.1
go runtime go1.21.6 linux/arm64
Copyright (c) 2022-2024 @daeuniverse
License GNU AGPLv3 <https://github.com/daeuniverse/dae/blob/main/LICENSE>
  • OS (e.g cat /etc/os-release):
    openwrt 23.05
  • Kernel (e.g. uname -a):
    5.15
  • Others:

Anything else?

No response

Thanks for opening this issue!

commented

@douglarek it's up to your dns routing, isn't it?

@douglarek it's up to your dns routing, isn't it?

That's certainly correct, but what's intriguing is that when I request api.miwifi.com, the _qname is api.miwifi.com.lan. This situation seems to occur when I set api.miwifi.com to 'reject'.

commented

@douglarek It is not dae's bussiness. Google it.

@douglarek It is not dae's bussiness. Google it.

Thank you for pointing that out. I found that this seems to be the local domain suffix in OpenWRT, which randomly appends '.lan' to certain domain names. After removing this local domain suffix, there is a noticeable difference.

[2024-01-30 update]: If your system is using systemd-resolved instead of dnsmasq, you need to disable DNS search domains. Here's how: edit /etc/systemd/resolved.conf, uncomment the line #Domains=, and change it to Domains=, then restart systemd-resolved and dae.