Client name lookup not working

[superadmin84]

Hello, I am attempting to configure client name lookup as described here. However, it does not appear to be working properly. It looks like initially it does the reverse lookup of my client, and then initiates a bunch of additional requests for the PTR record I requested. However, it seems that the Cloudflare NXDomain is returned. I'm not sure why the rDNS request for the client worked but not the actual requested record. Is this a race condition or something? I do see that a mapping feature is available, but I would prefer not to map every device as the router has the reverse lookup info. Any ideas whats wrong?

Expected:

 % nslookup 192.168.1.80 192.168.1.1
Server:		192.168.1.1
Address:	192.168.1.1#53

80.1.168.192.in-addr.arpa	name = server.localdomain.

Actual:

% nslookup 192.168.1.80
Server:		192.168.1.220
Address:	192.168.1.220#53

** server can't find 80.1.168.192.in-addr.arpa: NXDOMAIN

Logs:

blocky         | [2022-08-01 00:12:53] DEBUG server: new request
blocky         | [2022-08-01 00:12:53] DEBUG upstream_resolver: received response from upstream answer=PTR (Laptop.Client.) client_ip=192.168.10.250 net=tcp+udp protocol=TCP question=PTR (80.1.168.192.in-addr.arpa.) response_time_ms=0 return_code=NOERROR upstream=tcp+udp:192.168.1.1 upstream_ip=192.168.1.1
blocky         | [2022-08-01 00:12:53] DEBUG client_names_resolver: resolved client name(s) from external resolver client_ip=192.168.10.250 client_names=Laptop.Client question=PTR (80.1.168.192.in-addr.arpa.)
blocky         | [2022-08-01 00:12:53] DEBUG blacklist_resolver: checking groups for request client_ip=192.168.10.250 client_names=Laptop.Client groupsToCheck=ads question=PTR (80.1.168.192.in-addr.arpa.)
blocky         | [2022-08-01 00:12:53] DEBUG caching_resolver: not in cache: go to next resolver client_ip=192.168.10.250 client_names=Laptop.Client domain=80.1.168.192.in-addr.arpa next_resolver=ConditionalUpstreamResolver question=PTR (80.1.168.192.in-addr.arpa.)
blocky         | [2022-08-01 00:12:53] DEBUG parallel_best_resolver: delegating to resolver client_ip=192.168.10.250 client_names=Laptop.Client question=PTR (80.1.168.192.in-addr.arpa.) resolver=upstream 'https://1.1.1.1/dns-query'
blocky         | [2022-08-01 00:12:53] DEBUG upstream_resolver: received response from upstream answer= client_ip=192.168.10.250 client_names=Laptop.Client net=https protocol=UDP question=PTR (80.1.168.192.in-addr.arpa.) response_time_ms=12 return_code=NXDOMAIN upstream=https://1.1.1.1/dns-query upstream_ip=1.1.1.1
blocky         | [2022-08-01 00:12:53]  INFO queryLog: query resolved answer= client_ip=192.168.10.250 client_names=Laptop.Client duration_ms=12 question=PTR (80.1.168.192.in-addr.arpa.) response_code=NXDOMAIN response_reason=RESOLVED (https://1.1.1.1/dns-query)

Config:

bootstrapDns:
  upstream: https://1.1.1.1/dns-query
  ips:
    - 1.1.1.1
    - 1.0.0.1
upstream:
  default:
    - https://1.1.1.1/dns-query
clientLookup:
  upstream: 192.168.1.1
blocking:
  blockType: nxDomain
  failStartOnListError: true
  blackLists:
    ads:
      - https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
      - https://hblock.molinero.dev/hosts
      - https://raw.githubusercontent.com/sjhgvr/oisd/main/dbl_full.txt
  clientGroupsBlock:
    default:
      - ads
port: 53
logLevel: debug

[kwitsch]

You need to add a conditional block:

conditional:
  mapping:
    168.192.in-addr.arpa: 192.168.1.1
    .: 192.168.1.1

[superadmin84]

Interesting. Reading the configuration docs, clientLookup and conditional DNS seem to be independent features. Is it required to use conditional DNS with clientLookup, or is the conditional completely replacing the need for clientLookup in the config? If it’s the former, there should be some notes in the documentation that indicate this is necessary.

[kwitsch]

clientLookup is for blocky itself (log entries & blocklists)

If you want rdns to be resolved you need to redirect the requests to an appropriate server.
Same goes for non FQDN requests(your computer name without a domain). Those can be redirected with "."