search

AdguardTeam / AdGuardHome

Network-wide ads & trackers blocking DNS server
https://adguard.com/adguard-home.html
GNU General Public License v3.0
25.15k stars 1.81k forks source link

rdns: exchanger: no upstreams specified #2928

Closed bcookatpcsd closed 3 years ago

bcookatpcsd commented 3 years ago

Not sure why this is happening all of a sudden..

docker adguard:edge [v0.106.0-a.97+65553a29]

2021/04/06 11:23:20 [error] rdns: resolving "10.20.1.131": performing lookup for "131.1.20.10.in-addr.arpa.": exchanger: no upstreams specified 2021/04/06 11:23:22 [error] rdns: resolving "10.20.77.130": performing lookup for "130.77.20.10.in-addr.arpa.": exchanger: no upstreams specified

tls://dns.google https://dns.nextdns.io/dns-query [/20.10.in-addr.arpa/]172.16.254.241:53 [/120.10.in-addr.arpa/]172.16.254.241:53 [/pcsd/]172.16.254.241:53 [/pcsd.local/]10.20.1.101:53

~# docker exec -it adguardedge sh /opt/adguardhome/work # nslookup -type=ptr -debug 69.0.20.10.in-addr.arpa 172.16.254.241 Server: 172.16.254.241 Address: 172.16.254.241:53

Query #0 completed in 0ms: 69.0.20.10.in-addr.arpa name = proxy.tech.pcsd

/opt/adguardhome/work # nslookup -type=ptr -debug 69.0.20.10.in-addr.arpa 10.20.0.63 Server: 10.20.0.63 Address: 10.20.0.63:53

Query #0 completed in 0ms: ** server can't find 69.0.20.10.in-addr.arpa: NXDOMAIN

drill -x 10.20.0.69 @172.16.254.241 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25969 ;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; 69.0.20.10.in-addr.arpa. IN PTR

;; ANSWER SECTION: 69.0.20.10.in-addr.arpa. 300 IN PTR proxy.tech.pcsd.

drill -x 10.20.0.69 @10.20.0.43 ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 35097 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;; 69.0.20.10.in-addr.arpa. IN PTR

;; ANSWER SECTION:

;; AUTHORITY SECTION: 69.0.20.10.in-addr.arpa. 10 IN SOA fake-for-negative-caching.adguard.com. hostmaster.69.0.20.10.in-addr.arpa. 100500 1800 900 604800 86400

Go back to 105.2.. [latest or beta works fine, seems to be just edge]

drill -x 10.20.0.69 @10.20.0.43 ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 1994 ;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; 69.0.20.10.in-addr.arpa. IN PTR

;; ANSWER SECTION: 69.0.20.10.in-addr.arpa. 2400 IN PTR proxy.tech.pcsd.

All good..

ainar-g commented 3 years ago

Thanks for the report! @EugeneOne1 is currently working on #2704, and this is probably one of the bugs in there. Once it is done, you won't need those .arpa rules, because you'll be able to set a separate list of resolvers for local PTR queries. I've messaged him about your issues, and we'll fix it in the nearest couple of days.

EugeneOne1 commented 3 years ago

@bcookatpcsd, hello again. We've just finished with #2704, which is available in the latest edge builds, and also updated the wiki section about rDNS. You may now specify the upstreams for resolving requests for local addresses (which are used by rDNS) via web interface in "Upstream DNS servers" section or via AdGuardHome.yaml by local_ptr_upstreams setting. Note that this setting also makes an entire DNS server forward PTRs for local addresses to the specified upstream.

I suppose, in your case, it should be configured like: image In case of configuring via .yaml is like:

'local_ptr_upstreams':
- '172.16.254.241:53'

And you may also remove these lines with .arpa from the upstreams since they are useless anymore. Could you please try and check this solution? If it doesn't help, please, provide more information about your system setup.

bcookatpcsd commented 3 years ago

Will update to edge and let you know..

Sorry for the questions.. (always questions.. - sorry)

Looks like the same [/16.172.in-addr.arpa/]10.9.8.7:5353 is still there.. (correct?) and processing happens from top to bottom..

(thinking outloud) Is this like unbound where you say private-address private-domain?

OT: What my other usecase is.. pfblockerNG.. does tons of ptr checks (which I cannot seem to disable..) so I try and sinkhole those..

Thanks in advance..

EugeneOne1 commented 3 years ago

These upstreams are only for resolving the addresses from locally-served networks (i.e. only the ones from RFC-6303). PTRs for other IP ranges are handled as before.

I can't find any mention of [/16.172.in-addr.arpa/]10.9.8.7:5353 in your previous messages, but the 16.172.in-addr.arpa is also included in "private" registries which means it also forwarded to these special upstreams. So, responding to the question about multiple servers (if I understood it correctly), you should put the 10.9.8.7:5353 in the second line of the above setting.

Generally, it's better to ask such questions and propose such features in GitHub discussions. Thank you for your time.

bcookatpcsd commented 3 years ago

https://zerobin.net/?1910ae890fdf2bce#NgUSbpXI7IIz6xToUKKe4fLPcVFFaVWsYsArOnF4v/U= Logs and details

https://zerobin.net/?616b58272962cfd4#jA79fT6noQ1MgX+KK9nrBZ66LoMGrQuI2km/vVGQ3xQ= Configuration

autohost_tld: lan resolve_clients: true local_ptr_upstreams:

Looks like it worked with the local_ptr_upstream

drill -x 1.2.3.4 @192.168.10.210

worked and I got back the ptr I should.

the ttl was always the same, so it looked like 192.168.10.210 never cached the answer

I have 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24, and 172.16.254.0/24 .. all resolved as it should but gave the same 2400

cache_ttl_min: 2400 cache_ttl_max: 2400

I was surprised to see Adguard browsing security web service looking at my internal queries.. that must be quite a hit on the server.. 295ms

2021/04/12 20:25:23 1#99 [debug] github.com/AdguardTeam/dnsproxy/proxy.(Proxy).udpHandlePacket(): Start handling new UDP packet from 192.168.10.122:52972 2021/04/12 20:25:23 1#99 [debug] github.com/AdguardTeam/dnsproxy/proxy.(Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 55191 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;sonoszp.vlan10.dns. IN A

2021/04/12 20:25:23 1#99 [debug] etchostscontainer: answer: sonoszp.vlan10.dns -> [] 2021/04/12 20:25:23 1#99 [debug] github.com/AdguardTeam/AdGuardHome/internal/dnsfilter.check(): SafeBrowsing: checking sonoszp.vlan10.dns: 9fe0.568e.dd75.sb.dns.adguard.com. 2021/04/12 20:25:23 1#99 [debug] https://dns-family.adguard.com:443/dns-query: sending request TXT 9fe0.568e.dd75.sb.dns.adguard.com. 2021/04/12 20:25:23 1#101 [debug] github.com/AdguardTeam/dnsproxy/upstream.(bootstrapper).createDialContext.func1(): Dialing to 94.140.14.15:443 2021/04/12 20:25:23 1#101 [debug] github.com/AdguardTeam/dnsproxy/upstream.(bootstrapper).createDialContext.func1(): dialer has successfully initialized connection to 94.140.14.15:443 in 18 milliseconds 2021/04/12 20:25:23 1#99 [debug] https://dns-family.adguard.com:443/dns-query: response: ok 2021/04/12 20:25:23 1#99 [debug] SafeBrowsing: received hashes for sonoszp.vlan10.dns: [8< -- SNIP -- >8] 2021/04/12 20:25:23 1#99 [debug] SafeBrowsing: stored in cache: [86 142] 2021/04/12 20:25:23 1#99 [debug] SafeBrowsing: stored in cache: [159 224] 2021/04/12 20:25:23 1#99 [debug] SafeBrowsing: stored in cache: [221 117] 2021/04/12 20:25:23 1#99 [debug] github.com/AdguardTeam/AdGuardHome/internal/dnsfilter.(*DNSFilter).checkSafeBrowsing(): SafeBrowsing lookup for sonoszp.vlan10.dns; Elapsed time: 295ms

Also the blocked_host entries:

blocked_hosts:

received a 15 second penalty..

time drill gw10 @192.168.10.210 Error: error sending query: Could not send or receive, because of network error

2021/04/12 20:49:54 1#149 [debug] github.com/AdguardTeam/dnsproxy/proxy.(Proxy).udpHandlePacket(): Start handling new UDP packet from 192.168.10.122:55315 2021/04/12 20:49:54 1#149 [debug] github.com/AdguardTeam/dnsproxy/proxy.(Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 2046 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;gw10. IN A

Latest docker image as of April 12th 20:00 EST

Hope this helps.

EugeneOne1 commented 3 years ago

It looks like you're trying to lookup for sonoszp.vlan10.dns., which is not detected as an internal host (the .lan one). So, it's processed as a usual request through the upstream, with filtering logic applied, etc. In your case, the used upstream is [/dns/]192.168.10.105:531 since it reacts on the .dns suffix, but I'd say that this is still expected behavior.

We currently have no way to determine if the hostname is from locally-served network except when it has your TLD suffix (.lan). Note also that this suffix is only for accessing DHCP-leased devices for now.

The blocked_hosts behavior is also expected since we do not respond on queries for blocked domains.

bcookatpcsd commented 3 years ago

2021/04/13 12:27:16 [info] SafeBrowsing: failed: couldn't do a GET request to 'https://dns-family.adguard.com:443/dns-query', cause: Get "https://dns-family.adguard.com:443/dns-query?dns=cnIBAAABAAAAAAAABDdkZjcEYjYyOAJzYgNkbnMHYWRndWFyZANjb20AABAAAQ": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

This was my fear with all the requests going to that filter.. what if that filter fails..

I will adjust the filter for lan.. does it only support a single tld?

Thank you in advance for everything..

EugeneOne1 commented 3 years ago

@bcookatpcsd, I'll close the issue for now, since the bug from its original statement seems to have been solved. We kindly ask you to use the GitHub Discussions section for additional and off-topic questions. And please feel free to open new issues about any bugs or crashes you encounter.