rDNS queries returning SERVFAIL do not show up in Query Log/FQDN rewrite bug

[agneevX]

Prerequisites

• I am running the latest version
• I checked the documentation and found no answer
• I checked to make sure that this issue has not already been filed

Environment

• Version of AdGuard Home server: 0.106.3
• How did you install AdGuard Home: GH Releases
• How did you setup DNS configuration: N/A
• If it's a router or IoT, please write device model: N/A
• CPU architecture: arm64
• Operating system and version: Ubuntu 20.04

Issue details

rDNS queries do not show up in Query Log, when SERVFAIL is returned.

E.g. with an incorrect syntax in a rule (more on that below):

||20.0.0.10.in-addr.arpa^$dnsrewrite=NOERROR;PTR;device.

Additional Information

When a custom rule is added like this, per the first example in your docs:

||20.0.0.10.in-addr.arpa^$dnsrewrite=NOERROR;PTR;device.

results in:

; <<>> DiG 9.16.1-Ubuntu <<>> -x 10.0.0.20 @10.0.0.10
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60309
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

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

However, eliminate the period at the end and it works:

||20.0.0.10.in-addr.arpa^$dnsrewrite=NOERROR;PTR;device

; <<>> DiG 9.16.1-Ubuntu <<>> -x 10.0.0.20 @10.0.0.10
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23924
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

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

;; ANSWER SECTION:
20.0.0.10.in-addr.arpa.	10	IN	PTR	device.
...

[ainar-g]

Hello, and thank you for the report. The dot-vs-no-dot definitely seems like a bug somewhere. I'm not sure about the SERVFAIL in logs, but I'll look at it.

[ainar-g]

The dot issue is fixed as of edge version v0.107.0-a.72+813102f2. Still looking at the SERVFAIL thing.

[ainar-g]

@agneevX, it looks like the non-logging of SERVFAIL is currently intentional. We generally do not add server or configuration errors into the query log, only into the plain text log. If you think that we should, it's better to make a new feature request issue, but if we decide to do that, we'll probably not be able until the new API and the new database are in, which will probably be no sooner than v0.109.0 cycle.

The FQDN issue should be fixed in v0.107.0-b.2, so I'll close this issue if you don't mind.