mirror of
https://github.com/AdguardTeam/AdGuardHome.git
synced 2026-03-04 00:01:12 -05:00
rdns: exchanger: no upstreams specified #2630
Labels
No labels
P1: Critical
P2: High
P3: Medium
P4: Low
UI
bug
cannot reproduce
compatibility
dependencies
docker
documentation
duplicate
enhancement
enhancement
external libs
feature request
good first issue
help wanted
infrastructure
invalid
localization
needs investigation
performance
potential-duplicate
question
recurrent
research
snap
waiting for data
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/AdGuardHome#2630
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bcookatpcsd on GitHub (Apr 6, 2021).
Originally assigned to: @EugeneOne1 on GitHub.
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 on GitHub (Apr 6, 2021):
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
.arparules, 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 on GitHub (Apr 9, 2021):
@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.yamlbylocal_ptr_upstreamssetting. 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:
In case of configuring via
.yamlis like:And you may also remove these lines with
.arpafrom 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 on GitHub (Apr 9, 2021):
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 on GitHub (Apr 9, 2021):
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:5353in your previous messages, but the16.172.in-addr.arpais 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 the10.9.8.7:5353in 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 on GitHub (Apr 12, 2021):
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 on GitHub (Apr 13, 2021):
It looks like you're trying to lookup for
sonoszp.vlan10.dns., which is not detected as an internal host (the.lanone). 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:531since it reacts on the.dnssuffix, 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_hostsbehavior is also expected since we do not respond on queries for blocked domains.@bcookatpcsd commented on GitHub (Apr 13, 2021):
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 on GitHub (Apr 16, 2021):
@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.