rDNS Server fail #4832

whyisthisbroken · 2022-08-12T06:25:45Z

Prerequisites

I have checked the Wiki and Discussions and found no answer
I have searched other issues and found no duplicates
I want to report a bug and not ask a question

Operating system type

DietPi

CPU architecture

64-bit ARM

Installation

GitHub releases or script from README

Setup

On one machine

AdGuard Home version

v0.108.0-b.11

Description

What did you do?

Update to the latest beta

Expected result

private rDNS Server works in the Beta 10 as expected.

Actual result

Beta 11 say that the private rDNS Server could not be used - rDNS doesnt work.
All IP´s are not resolved anymore.

Screenshots (if applicable)

Additional information

my configuration:

Upstream Server:

#CloudflareDNS
tls://one.one.one.one
https://dns.cloudflare.com/dns-query
#CloudflareDNSFamily
tls://security.cloudflare-dns.com
https://security.cloudflare-dns.com/dns-query
#Quad9DNS
tls://dns.quad9.net
https://dns.quad9.net/dns-query
#LocalrDNS
[/fritz.box/]192.168.178.1
[/ip6.arpa/]192.168.178.1
[/in-addr.arpa/]192.168.178.1
#[/ip6.arpa/]fd00::464e:6dff:fe24:8cb1

Private reverse DNS servers

192.168.178.10
fd00::4x4x:6xxx:fexx:xxxx (x is a example)

The text was updated successfully, but these errors were encountered:

EugeneOne1 · 2022-08-12T10:17:59Z

@whyisthisbroken, hello and thanks for the report. It's very likely our recent upstream test improvement's fault (See #4517 (comment)). Could you please perform a manual lookup from some machine within the network?

dig @192.168.178.10 -t ptr in-addr.arpa

Also, we'd like to check the verbose log. Could you please collect it and send to devteam@adguard.com?

Btw, I'm wondering if the section under #LocalrDNS is designed to resolve local domain names? If so, I should mention that it actually doesn't since all the local rDNS requests are resolved via upstreams within the Private reverse DNS servers. Moreover it doesn't even require upstream being specific for in-addr.arpa/ip6.arpa domain unless it's needed to separate these requests by local subnets (See the wiki page).

whyisthisbroken · 2022-08-12T10:29:07Z

Here is the dig...

root@DietPi:~# dig @192.168.178.10 -t ptr in-addr.arpa

; <<>> DiG 9.16.27-Debian <<>> @192.168.178.10 -t ptr in-addr.arpa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 480
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;in-addr.arpa.                  IN      PTR

;; Query time: 3 msec
;; SERVER: 192.168.178.10#53(192.168.178.10)
;; WHEN: Fri Aug 12 12:26:53 CEST 2022
;; MSG SIZE  rcvd: 41

the verbose log comes later (Saturday evening or sunday) - i must no going to a wedding ;)

EugeneOne1 · 2022-08-12T10:35:42Z

@whyisthisbroken, thanks. Could you please also try to resolve some real address of a device known to the 192.168.178.10 upstream?

dig @192.168.178.10 -x <real-device-ip>

Since now it more looks like an upstream issue and not AGH's one.

whyisthisbroken · 2022-08-12T10:41:17Z

Okay no problem...first of all... i have made a mistake.. it must be 192.168.178.1 and not 10 ...damn call me stupid xD

so here again:

root@DietPi:~# dig @192.168.178.1 -t ptr in-addr.arpa

; <<>> DiG 9.16.27-Debian <<>> @192.168.178.1 -t ptr in-addr.arpa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31920
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

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

;; Query time: 2015 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Fri Aug 12 12:40:36 CEST 2022
;; MSG SIZE  rcvd: 30

root@DietPi:~# dig @192.168.178.1 -x 192.168.178.100

; <<>> DiG 9.16.27-Debian <<>> @192.168.178.1 -x 192.168.178.100
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51526
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 3

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

;; ANSWER SECTION:
100.178.168.192.in-addr.arpa. 9 IN      PTR     TV-Wohnen.fritz.box.
100.178.168.192.in-addr.arpa. 9 IN      PTR     8adcc7dcaff66486.fritz.box.
100.178.168.192.in-addr.arpa. 9 IN      PTR     15360d61-7650-b391-506b-23f43b93fa43.fritz.box.

;; AUTHORITY SECTION:
100.178.168.192.in-addr.arpa. 9 IN      NS      fritz.box.

;; ADDITIONAL SECTION:
fritz.box.              9       IN      A       192.168.178.1
fritz.box.              9       IN      AAAA    fd00::464e:xxxxxxxxx
fritz.box.              9       IN      AAAA    2a00:6020:b4xxxxxxxxxxxxxx

EugeneOne1 · 2022-08-12T12:20:28Z

@whyisthisbroken, I see. The last comment sheds light on the issue. Could you please tell, which device resolves the local domain names (the one at 192.168.178.1)? The request processing time of 2015ms hints that the request may be forwarded to another upstream. Perhaps, we should use another domain to test private upstream servers.

Also, wouldn't you mind if I'll ask you to perform one more request?

dig @192.168.178.1 test

whyisthisbroken · 2022-08-13T11:24:47Z

So - i made some changes...

Upstream Servers OLD:

#LocalrDNS
[/fritz.box/]192.168.178.1
[/ip6.arpa/]192.168.178.1
[/in-addr.arpa/]192.168.178.1
#[/ip6.arpa/]fd00::464e:6dff:fe24:8cb1

Upstream Servers NEW:

#LocalrDNS
[/fritz.box/]192.168.178.1
#[/ip6.arpa/]192.168.178.1
#[/in-addr.arpa/]192.168.178.1
#[/ip6.arpa/]fd00::464e:6dff:fe24:8cb1

Here are the results now:

root@DietPi:~# dig @192.168.178.10 -t ptr in-addr.arpa

; <<>> DiG 9.16.27-Debian <<>> @192.168.178.10 -t ptr in-addr.arpa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65496
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;in-addr.arpa.                  IN      PTR

;; AUTHORITY SECTION:
in-addr.arpa.           2388    IN      SOA     b.in-addr-servers.arpa. nstld.iana.org. 2022072021 1800 900 604800 3600

;; Query time: 0 msec
;; SERVER: 192.168.178.10#53(192.168.178.10)
;; WHEN: Sat Aug 13 13:19:12 CEST 2022
;; MSG SIZE  rcvd: 109

root@DietPi:~# dig @192.168.178.1 -x 192.168.178.100

; <<>> DiG 9.16.27-Debian <<>> @192.168.178.1 -x 192.168.178.100
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4610
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 3

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

;; ANSWER SECTION:
100.178.168.192.in-addr.arpa. 9 IN      PTR     TV-Wohnen.fritz.box.
100.178.168.192.in-addr.arpa. 9 IN      PTR     Android.fritz.box.
100.178.168.192.in-addr.arpa. 9 IN      PTR     15360d61-7650-b391-506b-23f43b93fa43.fritz.box.

;; AUTHORITY SECTION:
100.178.168.192.in-addr.arpa. 9 IN      NS      fritz.box.

;; ADDITIONAL SECTION:
fritz.box.              9       IN      A       192.168.178.1
fritz.box.              9       IN      AAAA    fd00::464exxxxxxxxxx
fritz.box.              9       IN      AAAA    2a00:6020:b4xxxxxxxxxxxxxxxx

;; Query time: 0 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Sat Aug 13 13:20:59 CEST 2022
;; MSG SIZE  rcvd: 238

root@DietPi:~# dig @192.168.178.1 test

; <<>> DiG 9.16.27-Debian <<>> @192.168.178.1 test
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14571
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.                          IN      A

;; AUTHORITY SECTION:
test.                   9227    IN      SOA     localhost. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 0 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Sat Aug 13 13:21:35 CEST 2022
;; MSG SIZE  rcvd: 92

I think the problem is solved - it must be the Settings in the Upstream Server.
But my question is, why the PTR request connect to quad9 ? see screenshot.
i thought it was a local request

EugeneOne1 · 2022-08-15T09:36:25Z

@whyisthisbroken, great to hear.

AGH considers a PTR request private only when it's for an IP address from locally-served zones, for example:

1.0.168.192.in-addr.arpa
1.0.0.10.in-addr.arpa
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.f.ip6.arpa

EugeneOne1 added the waiting for data Waiting for users to provide more data. label Aug 12, 2022

whyisthisbroken closed this as completed Aug 14, 2022

ainar-g added question and removed waiting for data Waiting for users to provide more data. labels Sep 1, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rDNS Server fail #4832

rDNS Server fail #4832

whyisthisbroken commented Aug 12, 2022 •

edited

Loading

EugeneOne1 commented Aug 12, 2022 •

edited

Loading

whyisthisbroken commented Aug 12, 2022

EugeneOne1 commented Aug 12, 2022 •

edited

Loading

whyisthisbroken commented Aug 12, 2022

EugeneOne1 commented Aug 12, 2022

whyisthisbroken commented Aug 13, 2022

EugeneOne1 commented Aug 15, 2022

rDNS Server fail #4832

rDNS Server fail #4832

Comments

whyisthisbroken commented Aug 12, 2022 • edited Loading

Prerequisites

Operating system type

CPU architecture

Installation

Setup

AdGuard Home version

Description

What did you do?

Expected result

Actual result

Screenshots (if applicable)

Additional information

EugeneOne1 commented Aug 12, 2022 • edited Loading

whyisthisbroken commented Aug 12, 2022

EugeneOne1 commented Aug 12, 2022 • edited Loading

whyisthisbroken commented Aug 12, 2022

EugeneOne1 commented Aug 12, 2022

whyisthisbroken commented Aug 13, 2022

EugeneOne1 commented Aug 15, 2022

whyisthisbroken commented Aug 12, 2022 •

edited

Loading

EugeneOne1 commented Aug 12, 2022 •

edited

Loading

EugeneOne1 commented Aug 12, 2022 •

edited

Loading