strange PTR behaviour - fake-for-negative-caching.adguard.com

[pyxis1]

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

FreeBSD

CPU architecture

AMD64

Installation

Other (please mention in the description)

Setup

On a router, DHCP is handled by the router

AdGuard Home version

0.107.20

Description

Adguard Home v0.107.20 running on Opnsense

What did you do?

opnsense with ssh:

drill -p 5353 -x @127.0.0.1 192.168.1.1

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3934
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 1.1.168.192.in-addr.arpa.   IN   PTR

;; ANSWER SECTION:
1.1.168.192.in-addr.arpa.   86400   IN   PTR   lapstart.localdomain.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Fri Dec 9 18:25:40 2022
;; MSG SIZE rcvd: 76

====== IPV6 ======

drill -p 5353 -x @127.0.0.1 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 29204
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; 0.4.2.6.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa.   IN   PTR

;; ANSWER SECTION:
0.4.2.6.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.2.ip6.arpa.   86400   IN   PTR   lapstart.localdomain.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Fri Dec 9 18:28:50 2022
;; MSG SIZE rcvd: 124

=========================!

On macbook pro terminal and specifying dns to opnsense lan ipv4, also correct!
$ dig -x 192.168.1.1 @192.168.1.1
; <<>> DiG 9.10.6 <<>> -x 192.168.1.1 @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42655
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

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

;; ANSWER SECTION:
1.1.168.192.in-addr.arpa. 10   IN   PTR   lapstart.localdomain.
1.1.168.192.in-addr.arpa. 10   IN   PTR   lapstart.

;; Query time: 58 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Dec 09 18:32:55 CET 2022
;; MSG SIZE rcvd: 98

===============

only ipv6 gets weird....

Still the terminal on macbook pro gives this error with the lan/opnsense ipv6 ip:

dig -x 192.168.1.1 @2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240

; <<>> DiG 9.10.6 <<>> -x 192.168.1.1 @2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47056
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

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

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

;; Query time: 57 msec
;; SERVER: 2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240#53(2001:xxxx:xxxx:xxx:xxxx:xxxx:xxxx:6240)
;; WHEN: Fri Dec 09 18:33:10 CET 2022
;; MSG SIZE rcvd: 174

Expected result

PTR   lapstart.localdomain.

Actual result

fake-for-negative-caching.adguard.com

Screenshots (if applicable)

Additional information

[ainar-g]

Hello. This is the expected behaviour. You're querying AdGuard Home using an external IP address, so AdGuard Home replies with an NXDOMAIN response, in order to prevent users from outside of the network to scan local hostnames. The fake-for-negative-caching.adguard.com part is just there to make this negative response cacheable.

[pyxis1]

Hi and thank you for your reply. In this case however, the request does not come from outside.
I have ipv4 and ipv6 running on my LAN and all queries come from within the (LAN)network.
Adguard home does not get queries from outside/wan

[ainar-g]

Unless the address you're using is from the 2001:db8::/32 subnet, AdGuard will consider the request coming to 2001:… addresses as not locally served. Please read the section in our Wiki. If you want to use a different list of networks considered locally-served, you can change them using the private_networks field, which is also described on the same Wiki page.

[pyxis1]

sorry, thats my bad. I was not aware of the private_networks field. Is this field only configurable in the .yaml file directly and not in the GUI? I could not find it there and missed it.
When i added the LAN IPV6 range to the private_networks field (and allowed clients) it works! thnx

[EugeneOne1]

@pyxis1, yeah, it's only presented in the yaml configuration, since redefining the locally-served networks set isn't really a common use-case.