-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
sniffed dns request mismatch domain list #61
Comments
I've noticed this code and I wonder why it is commented. Line 58 in 9078bc2
|
clientservices.googleapis.com is not in |
Yes, you are right. I'm using a self build rule follows Loyalsoldier's way. And I believe the reason is not this, because we can see rules work in this log:
I think the reason is in dns sniff like this behavior diff
I think that domain to be resolved is not filled in sniff so it is mismatched in this code Line 58 in 9078bc2
|
The role of the sniffer is to identify the protocol, and the DNS domain name is handled in another code. |
Try 4801b6f |
I have added attr support to geosite, try SagerNet/sing-geosite@50c4bf7 |
It works. Thank you!
Awesome, I'll have it a try. |
Welcome
Description of the problem
When using dns rules to lookup domain for anti dns pollution, a weird mismatch behavior appears when a dns request is sniffed and redirected to internal dns, and mismatched in domain list.
For example, in the following log, first a tcp connection comes in and is sniffed domain clientservices.googleapis.com. This domain has service in mainland China and has @cn attribute in rule, and should be resolved in dns rule [0]., while mismatched and a remote dns record(blocked by gfw) is cached. Then, when route by domain, it is routed to direct, while get a cached and blocked ip when perform ipv4_only domain strategy. And the connection fails.
Version of sing-box
Server and client configuration file
Server and client log file
The text was updated successfully, but these errors were encountered: