Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug Report] Capturing an incorrect DNS qname #448

Closed
3 tasks done
douglarek opened this issue Jan 27, 2024 · 5 comments
Closed
3 tasks done

[Bug Report] Capturing an incorrect DNS qname #448

douglarek opened this issue Jan 27, 2024 · 5 comments

Comments

@douglarek
Copy link
Contributor

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

@dae-prow
Copy link
Contributor

dae-prow bot commented Jan 27, 2024

Thanks for opening this issue!

@mzz2017
Copy link
Contributor

mzz2017 commented Jan 27, 2024

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

@douglarek
Copy link
Contributor Author

douglarek commented Jan 27, 2024

@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'.

@mzz2017
Copy link
Contributor

mzz2017 commented Jan 27, 2024

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

@douglarek
Copy link
Contributor Author

douglarek commented Jan 27, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants