PTR requests not sent to the router

[diasdmhub]

AdGuard v0.107.53

I have a router that provides DHCP addresses and local DNS names. Each DNS record has a PTR address, so I've set the AdGuard "arpa" domain upstream server and the "Private reverse DNS servers" to the router.

Upstream DNS servers

# Local DNS server
[/in-addr.arpa/]192.168.8.1 fd01:192:168:8::1
[/ip6.arpa/]192.168.8.1 fd01:192:168:8::1
[//]192.168.8.1 fd01:192:168:8::1

Private reverse DNS servers

192.168.8.1
fd01:192:168:8::1

Whenever I try to query AdGuard for a PTR record, it fails to find the answer and responds with "NXDOMAIN".

$ dig @192.168.8.5 PTR 192.168.8.11
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33857

;; QUESTION SECTION:
;192.168.8.11.          IN  PTR

;; Query time: 23 msec
;; SERVER: 192.168.8.5#53(192.168.8.5) (UDP)

When I track queries in AdGuard interface, I can see that it receives the request and sends it to an external DNS server, not to the router.

So, I'm not sure why AdGuard is not sending requests to the router. Any thoughts on this matter?

Originally posted by @diasdmhub in https://github.com/AdguardTeam/AdGuardHome/discussions/7380

[whyisthisbroken]

You should use this settings instead

Fill it with your router IP and it should be done. The private ptr don't have to be in the upstream field.

Look at the wiki (especially*Notes) https://github.com/AdguardTeam/AdGuardHome/wiki/Configuration#upstreams-for-rdns

[diasdmhub]

I see.

The wiki actually gives an example where the upstream private range is entered in the main "upstream DNS servers" field. While the latter note says that "Entering something like [/192.in-addr.arpa/]192.168.8.8 into the main field will have no effect". This seems to be conflicting information.

So, it shouldn't matter if I put something in the main upstream field, since it "will have no effect".

Anyway, I removed the private range domain notation from the main "upstream DNS servers" field and the odd behavior remains the same.

Also, I forgot to mention previously that AdGuard is displaying this message in the "Private reverse DNS servers" field:

AdGuard Home could not determine suitable private reverse DNS resolvers for this system.

I'm not sure what's going on.

[diasdmhub]

I just noted a mistake. I was not querying AdGuard in the proper way.

The correct query with the "Dig" tool should use the -x option.

$ dig @192.168.8.5 -x 192.168.8.11

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3427
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3

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

;; ANSWER SECTION:
11.8.168.192.in-addr.arpa. 86400 IN PTR host.domain.name.
11.8.168.192.in-addr.arpa. 86400 IN PTR host.

;; ADDITIONAL SECTION:
host.domain.name.   86400   IN  A   192.168.8.11
host.           86400   IN  A   192.168.8.11

;; Query time: 4 msec
;; SERVER: 192.168.8.5#53(192.168.8.5) (UDP)

That way, the answer is correct.

However, when I do the query as before (dig @192.168.8.5 PTR 192.168.8.11), using the PTR query type, the AdGuard log does shows it as a PTR query and sends it to an upstream server, as shown in the comment above.

This makes no sense to me.

[tjharman]

However, when I do the query as before (dig @192.168.8.5 PTR 192.168.8.11), using the PTR query type, the AdGuard log does shows it as a PTR query and sends it to an upstream server, as shown in the comment above.

This makes no sense to me.

It's because you don't understand what you're trying to do :-) Try this:

dig @192.168.8.5 PTR 11.8.168.192.in-addr.arpa

That's the query that dig -x is sending, as you can clearly see in the output you posted above:

;; ANSWER SECTION:
11.8.168.192.in-addr.arpa. 86400 IN PTR host.domain.name.
11.8.168.192.in-addr.arpa. 86400 IN PTR host.