search

AdguardTeam / AdGuardHome

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

rDNS does not work for IPv4 #5882

Closed merlinscholz closed 1 year ago

merlinscholz commented 1 year ago

Prerequisites

Operating system type

Linux, Other (please mention the version in the description)

CPU architecture

AMD64

Installation

GitHub releases or script from README

Setup

Other (please mention in the description)

AdGuard Home version

v0.107.31

Description

What did you do?

Setup reverse DNS to resolve everything via 100.100.100.100 (Tailscale magicDNS server)

Expected result

I should be able to:

  1. See IPv4 and IPv6 reverse DNS names in the web UI
  2. Have AdGuard Home return correct reverse DNS names for both IPv4 and IPv6 IPs

Actual result

  1. The web UI only shows IPv6 rDNS properly
  2. rDNS requests (tested via dig) only work for IPv6

Screenshots (if applicable)

image

Additional information

rDNS works correctly if I query the upstream rDNS server (100.100.100.100) via dig from the machine AdGuard Home is running on:

root@adguard:~# dig +short -x 100.127.54.98 @100.100.100.100
macbook.REDACTED.ts.net.
root@adguard:~# dig +short -x fd7a:115c:a1e0:ab12:4843:cd96:627f:3662 @100.100.100.100
macbook.REDACTED.ts.net.
root@adguard:~# dig +short -x 100.127.54.98 @localhost
root@adguard:~# dig +short -x fd7a:115c:a1e0:ab12:4843:cd96:627f:3662 @localhost
macbook.REDACTED.ts.net.
agneevX commented 1 year ago

Please share your Private reverse DNS servers config.

merlinscholz commented 1 year ago 
fd7a:115c:a1e0::53
100.100.100.100

image

The problem persists when only using either one of the addresses. Both addresses point to the same virtual DNS server and are reachable by AdGuard (as can be seen in the initial post)

ainar-g commented 1 year ago

Hello and thank you for the thorough report. Could you enable the verbose logging and see if there are any clues there? In particular, the logs regarding the rDNS resolving of clients should be prefixed with rdns:.

merlinscholz commented 1 year ago

Here are the relevant sections (not prefixed with rdns: btw) after a fresh run without any caches:

Working IPv6 request:

2023/06/13 12:55:11.044888 2406#885 [debug] dnsproxy: handling new udp packet from 10.0.10.50:59662
2023/06/13 12:55:11.045013 2406#885 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 42110
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags:; udp: 4096

;; QUESTION SECTION:
;2.6.6.3.f.7.2.6.6.9.d.c.3.4.8.4.2.1.b.a.0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa.  IN   PTR

2023/06/13 12:55:11.045145 2406#885 [debug] applying filters: looking for client with ip 10.0.10.50 and clientid ""
2023/06/13 12:55:11.045270 2406#885 [debug] applying filters: no clients with ip 10.0.10.50 and clientid ""
2023/06/13 12:55:11.045375 2406#885 [debug] dnsforward: addr fd7a:115c:a1e0:ab12:4843:cd96:627f:3662 is from locally served network
2023/06/13 12:55:11.045485 2406#885 [debug] hosts container: handling the request for 2.6.6.3.f.7.2.6.6.9.d.c.3.4.8.4.2.1.b.a.0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa
2023/06/13 12:55:11.045636 2406#885 [debug] dnsproxy: cache: disabled; not caching
2023/06/13 12:55:11.045775 2406#885 [debug] [fd7a:115c:a1e0::53]:53: sending request over udp: PTR 2.6.6.3.f.7.2.6.6.9.d.c.3.4.8.4.2.1.b.a.0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa.
2023/06/13 12:55:11.045890 2406#885 [debug] bootstrap: dialing [fd7a:115c:a1e0::53]:53 (1/1)
2023/06/13 12:55:11.046128 2406#885 [debug] bootstrap: connection to [fd7a:115c:a1e0::53]:53 succeeded in 137.476µs
2023/06/13 12:55:11.046863 2406#885 [debug] [fd7a:115c:a1e0::53]:53: response received over udp: ok
2023/06/13 12:55:11.047059 2406#885 [debug] time.Duration.Milliseconds(): upstream [fd7a:115c:a1e0::53]:53 successfully finished exchange of ;2.6.6.3.f.7.2.6.6.9.d.c.3.4.8.4.2.1.b.a.0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa. IN   PTR. Elapsed 1.25061ms.
2023/06/13 12:55:11.047161 2406#885 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).replyFromUpstream(): RTT: 1.427117ms
2023/06/13 12:55:11.047246 2406#885 [debug] client ip: 10.0.10.50
2023/06/13 12:55:11.047528 2406#885 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; opcode: QUERY, status: NOERROR, id: 42110
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags:; udp: 4096

;; QUESTION SECTION:
;2.6.6.3.f.7.2.6.6.9.d.c.3.4.8.4.2.1.b.a.0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa.  IN   PTR

;; ANSWER SECTION:
2.6.6.3.f.7.2.6.6.9.d.c.3.4.8.4.2.1.b.a.0.e.1.a.c.5.1.1.a.7.d.f.ip6.arpa.   600 IN  PTR macbook.REDACTED.ts.net.

Broken IPv4 request:

2023/06/13 12:55:11.054276 2406#886 [debug] dnsproxy: handling new udp packet from 10.0.10.50:59004
2023/06/13 12:55:11.054401 2406#886 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): IN: ;; opcode: QUERY, status: NOERROR, id: 40780
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags:; udp: 4096

;; QUESTION SECTION:
;98.54.127.100.in-addr.arpa.    IN   PTR

2023/06/13 12:55:11.054519 2406#886 [debug] applying filters: looking for client with ip 10.0.10.50 and clientid ""
2023/06/13 12:55:11.054604 2406#886 [debug] applying filters: no clients with ip 10.0.10.50 and clientid ""
2023/06/13 12:55:11.054712 2406#886 [debug] hosts container: handling the request for 98.54.127.100.in-addr.arpa
2023/06/13 12:55:11.054903 2406#886 [debug] dot upstream: using existing conn 9.9.9.10:853
2023/06/13 12:55:11.055095 2406#886 [debug] tls://dns10.quad9.net:853: sending request over tcp: PTR 98.54.127.100.in-addr.arpa.
2023/06/13 12:55:11.068141 2406#886 [debug] tls://dns10.quad9.net:853: response received over tcp: ok
2023/06/13 12:55:11.068290 2406#886 [debug] time.Duration.Milliseconds(): upstream tls://dns10.quad9.net:853 successfully finished exchange of ;98.54.127.100.in-addr.arpa. IN   PTR. Elapsed 13.396058ms.
2023/06/13 12:55:11.068395 2406#886 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).replyFromUpstream(): RTT: 13.519982ms
2023/06/13 12:55:11.068512 2406#886 [debug] client ip: 10.0.10.50
2023/06/13 12:55:11.068671 2406#886 [debug] github.com/AdguardTeam/dnsproxy/proxy.(*Proxy).logDNSMessage(): OUT: ;; opcode: QUERY, status: NXDOMAIN, id: 40780
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version 0; flags:; udp: 4096

;; QUESTION SECTION:
;98.54.127.100.in-addr.arpa.    IN   PTR

;; AUTHORITY SECTION:
127.100.in-addr.arpa.   1486    IN  SOA sns.dns.icann.org. noc.dns.icann.org. 2022072100 7200 3600 604800 3600

Both should be pointing to the same hostname.

It seems to me like the CGNAT subnet Tailscale uses internally (100.64.0.0/10) is not being recognized as "locally served network" as per Go's netutil.IsLocallyServed, which itself is derived from RFC 6303. Thus, replacing the the section in the config file with an extended version yields the correct results for IPv4 and IPv6:

private_networks:
  - 100.64.0.0/10
  - 10.0.0.0/8
  - 127.0.0.0/8
  - 169.254.0.0/16
  - 172.16.0.0/12
  - 192.0.2.0/24
  - 192.168.0.0/16
  - 198.51.100.0/24
  - 203.0.113.0/24
  - 255.255.255.255/32
  - ::/128
  - ::1/128
  - 2001:db8::/32
  - fd00::/8
  - fe80::/10

That 100.64.0.0/10 is not a "locally served network" is correct and implemented correctly. The question now remains whether AdGuard Home should try to resolve PTR records by itself (via the specified reverse resolvers) first for non-"locally served networks" before reaching out to upstream.

ainar-g commented 1 year ago

Thanks again for the investigation. The Private reverse DNS servers field is indeed used when an IP address is recognized as private, and if the default networks do not include your VPN's (Tailscale's, in this case), then adding it to the list should fix the issue.

The question now remains whether AdGuard Home should try to resolve PTR records by itself (via the specified reverse resolvers) first for non-"locally served networks" before reaching out to upstream.

I'm not sure I follow you here, sorry. By default, the upstreams in the main upstream input are used for all requests. The Private reverse DNS servers feature is mostly to protect users against leaking local PTR queries to the default upstreams, which are often public.

merlinscholz commented 1 year ago

That makes total sense, thanks for your response. I'll just leave the 100.64.0.0/10 in the private_networks config since everything seems to be intended behaviour.

Thank you!