ERROR reflow::relay::listen::socks: error handling client Error resolving www.google.com: No connections available

[developerdong]

hi, I got an error when I want to access google: ERROR reflow::relay::listen::socks: error handling client Error resolving www.google.com: No connections available

And the content of config file is:

# declare a socks5 proxy called shadowsocks
egress shadowsocks = socks5 127.0.0.1:1081

# you can configure a dns proxy that will forward queries to different upstream servers depending on what domain name is being queried
dns{
   # use this address as your DNS server
   listen=udp 127.0.0.1:53
   forward= {
       # if a domain name is in the zone "blacklist"
       # connect to the upstream server 8.8.8.8 via a socks5 proxy defined earlier
       blacklist => shadowsocks|udp 8.8.8.8:53
       # use the dnspod dns server for everything else
       else => udp 119.29.29.29:53
   }
}

# you can configure one or more relays
relay {
 rule=breakwall
 listen=socks5 0.0.0.0:1080
 # you can optionally set a dns server
 # it will use 8.8.8.8 by default if the option is omitted
 resolver=udp 127.0.0.1:53
}

# a decision tree named breakwall
rule breakwall= any[ # rules enclosed in "any[ ]" will be tried one by one util a rule matches
    # first look at the domain name
    cond domain {
      whitelist => direct
    }

    # next look at ip addresses
    cond ip {
        whitelist => direct
    }

    # catch-all rule for everything else
    shadowsocks
]

www.google.com is in my blacklist name zone, I think the dns request will be sent to 8.8.8.8 through
a socks server named shadowsocks when I want to access www.google.com, but I got the aforementioned error. Is reflow configured incorrectly?

[bitsmut]

@developerdong there's nothing wrong with the configuration. It should do what you expect. Could you check the status of the socks5 proxy, is it receiving the proxy request correctly?

[bitsmut]

@developerdong are you running it as root? since you're using a privileged port: listen=udp 127.0.0.1:53. If reflow fails to use a port, it will print an error, but will continue to run

by the way, you can get more output by setting the environment variable RUST_LOG, using RUST_LOG=reflow=debug, you can see debug messages

[developerdong]

Thanks a lot. I will try your advice, and comment here if I make any progress.

[developerdong]

@developerdong are you running it as root? since you're using a privileged port: listen=udp 127.0.0.1:53. If reflow fails to use a port, it will print an error, but will continue to run

by the way, you can get more output by setting the environment variable RUST_LOG, using RUST_LOG=reflow=debug, you can see debug messages

Yes, actually the reflow is running inside a docker container, and the default user in container is root. I have tried to use port 5353, but nothing changed.

[bitsmut]

@developerdong judging by the error messages, it happens when reflow is internally using 127.0.0.1:53 to resolve www.google.com. I think it's a good idea to test the dns proxy separately, use dig @127.0.0.1 -p 53 www.google.com and see what happens. Also, does it matter what upstream dns (case blacklist or else) is being used? Try some domains in blacklist and some that are not. Let's start here and try to further trace down the problem

[developerdong]

@developerdong thanks for trying it out! there's nothing wrong with the configuration syntax, otherwise you'll see error messages at once when you start it. It should do what you expect. Could you check the status of the socks5 proxy, is it receiving the proxy request correctly? Or could you use wireshark to check packets going through 127.0.0.1? Sorry I can't figure out the problem or the fix right away In the mean time, I'll check the code again and see if there are bugs, or maybe I can make error messages clearer.

The logs of socks proxy show that the dns request is accepted, and the debug messages of reflow indicate a new warning: WARN reflow::resolver::serve: erro: resolve error: Os { code: 11, kind: WouldBlock, message: "Resource temporarily unavailable" } What does this message mean?

[bitsmut]

@developerdong One possibility is that the DNS resolution isn't working, and it keeps opening new sockets, until the number reaches the maximum, and it can't continue temporarily.

Do you get the same error when you use shadowsocks|udp 8.8.8.8:53 and udp 119.29.29.29:53 ? How about shadowsocks|tcp 8.8.8.8:53? DNS over tcp should have better compatibility with all kinds of socks5 proxies

[developerdong]

@developerdong One possibility is that the DNS resolution isn't working, and it keeps opening new sockets, until the number reaches the maximum, and it can't continue temporarily.

Do you get the same error when you use shadowsocks|udp 8.8.8.8:53 and udp 119.29.29.29:53 ? How about shadowsocks|tcp 8.8.8.8:53? DNS over tcp should have better compatibility with all kinds of socks5 proxies

After setting blacklist resolver to shadowsocks|tcp 8.8.8.8:53, command dig @127.0.0.1 -p 53 www.google.com returns correct result, why did this change take effect?

Secondly, I tried to access some domain like www.ipip.net, which is not in blacklist, but failed. The dig result of command dig @127.0.0.1 -p 53 www.ipip.net is:

; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> @127.0.0.1 -p 53 www.ipip.net
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

I also tried to connect 119.29.29.29 directly using dig @119.29.29.29 -p 53 www.ipip.net,
and the result is the same:

; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> @119.29.29.29 -p 53 www.ipip.net
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

When I add a argument +noedns to the command dig @119.29.29.29 +noedns -p 53 www.ipip.net, the request is successful:

; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> @119.29.29.29 +noedns -p 53 www.ipip.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21763
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.ipip.net.                  IN      A

;; ANSWER SECTION:
www.ipip.net.           368     IN      CNAME   75899baf9bb33b92.cdn.jiashule.com.
75899baf9bb33b92.cdn.jiashule.com. 22 IN A      180.97.158.121

;; Query time: 40 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Fri Oct 26 02:47:51 UTC 2018
;; MSG SIZE  rcvd: 93

Is there any compatibility problem with DNS server supporting EDNS?

[bitsmut]

@developerdong socks5 proxies can support udp, but not all implementations support it equally well, there are times when tcp works fine but udp doesn't for some reason. This may be the case.

EDNS doesn't matter to reflow, it just parses DNS queries to extract the domain name, the query is forwarded without any change.

[developerdong]

I have switched 119.29.29.29 to another DNS Server, and requests to domains, which are not in the blacklist, are correct. There is no problem now. Thank you.