what will happen if china-dns return 127.0.0.1 about chinadns-ng

[zfl9]

Yes.

[zfl9]

Of course you can remove any address from chnroute.ipset, depending on yourself.

[zfl9]

The reason for adding these addresses such as 127.0.0.1 by default is that when the upstream of china-dns is the internal dns server, the normal parsing result including these ips may occur.

[xlighting2017]

Thanks, so I think there is a "flaw" here...
for example, if I'm working in an Intranet, while the upstream ISP DNS has pollution the result with addresses like 127.0.0.1, I'll be in trouble...

---

it's the "ignore any other results" that causes the "flaw"
how about we "wait until both DNSs return, and compare the results"?

---

Edit: this is not a good solution too, I think we may need a better idea...

[zfl9]

There is no perfect solution, but there are many ways to avoid this:

1. Use dnsmasq as the dns server, for gfwlist domain names, tell dnsmasq, use 8.8.8.8 dns server (via proxy), for other domain names, use chinadns-ng to resolve them. This is the solution for ss-tproxy v4.x. This can avoid 99% of special cases.
2. Remove these special addresses and reserved addresses from chnroute.ipset, chnroute6.ipset.

[zfl9]

After actual testing, I think the first solution is the closest to perfection.
It is compatible with most usage scenarios.

[xlighting2017]

hmmm, I was hoping to reduce the dependency of other components, especially dnsmasq;(for its bad performance in searching/parsing long config files)

anyway, thanks for the effort!

[zfl9]

If you don't like dnsmasq, you can customize chnroute.ipset yourself. This method is also very simple and effective.