I have observed one weired thing. In my home LAN network there are two dietpi machines (one nuc and one raspberryPi). In raspberrypi I have installed bitwarden, homeassisttant & mqtt brocker via dietpi software. On nuc only docker & docker compose via dietpi-software (through docker compose plex,adguard, unbound & wireguard) both machines are running happily. But I observed both machines send PTR request to adguard (XX.1.168.192.in-addr.arpa). raspberry send PTR request to whole lan (192.168.1.1 to 192.168.1.254) every hour and in nuc side these request are coming after each 10 minute interval (only active lan devicies & docker internal network). So my question, is there any way to remove this reverse lan scan lookup thing as it unnecessary send request to dns resolver. Each day these are creating about 6K PTR request to my unbound system. In pihole or adguard forum it shown it is default patron but why reaspberry pi also sending these type of requests.
Hi,
not sure if this is something special. I see similar request created by my Windows laptop
00:02:38.375799 IP 192.168.0.54.49748 > 192.168.0.11.53: 50476+ PTR? 11.0.168.192.in-addr.arpa. (43)
00:02:38.375808 IP 192.168.0.54.53397 > 192.168.0.11.53: 41315+ PTR? 9.0.168.192.in-addr.arpa. (42)
00:02:38.376140 IP 192.168.0.11.53 > 192.168.0.54.49748: 50476* 1/0/0 PTR wpad.lan. (65)
00:02:38.376343 IP 192.168.0.11.53 > 192.168.0.54.53397: 41315* 1/0/0 PTR GS1900.lan. (66)
nslookup 192.168.0.54
54.0.168.192.in-addr.arpa name = Surface.lan.
You could try to raise the TTL of the PTR records. I suppose they are set to an hour, you could then make it a day.
what is the procedure to raise the TTL of the PTR records? i will very happy to raise it for one day if it is not breaking anything. as most of my devises are fixed by router DHCP reservation.
It depends on the nameserver running the zone with the PTR records.
That means the router or AdGuard, depending on where the LAN hostnames are resolved. But I never saw such a TTL option in any router or Pi-hole, at least not in the regular GUIs 
, not sure if AdGuard has it?
Another idea would be to prevent the reverse lookups at the client side, where possible. E.g. Apache2 has the HostnameLookups option which leads to a reverse lookup for each client access (disabled by default) for logs. And other software might do the same, to have hostnames instead of IPs in their logs, dashboards or such. Is there a way to find the original process on a Linux system which does the (reverse) DNS lookup (through glibc)?
In dnsmasq there is --dhcp-ttl= for the records created by the dhcp or --local-ttl= for the entries in /etc/hosts. Since Pihole is basically a dnsmasq on steroids, the same applies there.
in this case OP is using AdGuard Home on Docker.
It seems that the local nameserver is unbound, so the ttl change must be applied there.
At least if the PTR requests are not answered before. If DNS requests go like
Client => Router => AdGuard Home => Unbound
then also the router and AdGuard Home could answer them for LAN IPs/hostnames. But in this case you’re absolutely right:
Has AdGuard an own DNS cache, like Pi-hole? Pi-hole by default respects the TTL of the upstream DNS, but probably in AdGuard it can be forced to cache responses longer, probably even for certain request types? It doesn’t make a large difference here, when Unbound runs on the same system, but generally always good to reduce the hops for unnecessary requests as much as possible 
.
Just to be clear, I don’t use adguard nor unbound, therefore I am not aware of their bits and bytes. But, yes, my gut says that TTL values should be honored downstream by default.
Please suggest me what i have to do in simple way. I already have A-record file in this format ’ local-data-ptr: “192.168.1.12 60 host.name”
local-data: “host.name. 60 A 192.168.1.12” ` in unbound. but this thing is only valid for known lan devices. raspberrpi send the dns request to unused lan ip addresses also. if this is issue related to upstream dns server then what you suggest for my raspberry custom upstream DNS would be for all other lan network devises my upstream dns server is 192.168.1.90 (through router) but for docker host machine(172.28.0.1) what should be our custom upstream dns server of raspberry pi running at 192.168.1.74 (192.168.1.90 [adguard/unbound/docker host], 172.28.0.2:53 [docker adguard], 172.28.0.3:5335 [docker unbound] or 1.1.1.1[external]) or 192.168.1.254[DHCP Server router]. if you see the screen shot raspberry pi send request to unbound for unused lan ip also.
Create dummy entries for unused IPs too.
is i have to write for each lan address 192.168.1.1 to 192.168.1.254? even if i write it its not making much difference. it will again send 254 requests for each ip & known A-Record will reply NOERROR & unknown will NXDOMAIN. the end result each hour unnecessary 254 PTR request to unbound.
Response details
Status
Processed
DNS server
172.28.0.3:5335
Elapsed
0.99 ms
Response code
NXDOMAIN
Response details
Status
Processed
DNS server
172.28.0.3:5335
Elapsed
0.87 ms
Response code
NOERROR
Response
PTR: rpi.local. (ttl=3600)
My unbound.conf is copied & modify from dietpi default template unbound.conf
# https://nlnetlabs.nl/documentation/unbound/unbound.conf/
server:
# Do not daemonize, to allow proper systemd service control and status estimation.
do-daemonize: no
# A single thread is pretty sufficient for home or small office instances.
num-threads: 1
# Logging: For the sake of privacy and performance, keep logging at a minimum!
# - Verbosity 2 and up practically contains query and reply logs.
verbosity: 0
log-queries: no
log-replies: no
# - If required, uncomment to log to a file, else logs are available via "journalctl -u unbound".
#logfile: "/var/log/unbound.log"
# Set interface to "0.0.0.0" to make Unbound listen on all network interfaces.
# Set it to "127.0.0.1" to listen on requests from the same machine only, useful in combination with Pi-hole.
interface: 0.0.0.0
# Default DNS port is "53". When used with Pi-hole, set this to e.g. "5335", since "5353" is used by mDNS already.
port: 5335
# Control IP ranges which should be able to use this Unbound instance.
# The DietPi defaults permit access from official local network IP ranges only, hence requests from www are denied.
access-control: 0.0.0.0/0 refuse
access-control: 10.0.0.0/8 allow
access-control: 127.0.0.1/8 allow
access-control: 172.16.0.0/12 allow
access-control: 192.168.0.0/16 allow
access-control: ::/0 refuse
access-control: ::1/128 allow
access-control: fd00::/8 allow
access-control: fe80::/10 allow
# Private IP ranges, which shall never be returned or forwarded as public DNS response.
# NB: 127.0.0.1/8 is sometimes used by adblock lists, hence DietPi by default allows those as response.
private-address: 10.0.0.0/8
private-address: 172.16.0.0/12
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: fd00::/8
private-address: fe80::/10
# Define protocols for connections to and from Unbound.
# NB: Disabling IPv6 does not disable IPv6 IP resolving, which depends on the clients request.
do-udp: yes
do-tcp: yes
do-ip4: yes
do-ip6: yes
prefer-ip6: no
# DNS root server information file. Updated monthly via cron job: /etc/cron.monthly/dietpi-unbound
# root-hints: "/var/lib/unbound/root.hints"
# Maximum number of queries per second
ratelimit: 1000
# Defend against and print warning when reaching unwanted reply limit.
unwanted-reply-threshold: 10000
# Set EDNS reassembly buffer size to match new upstream default, as of DNS Flag Day 2020 recommendation.
edns-buffer-size: 1232
# Increase incoming and outgoing query buffer size to cover traffic peaks.
# so-rcvbuf: 4m
# so-sndbuf: 4m
# Hardening
harden-glue: yes
harden-dnssec-stripped: yes
harden-algo-downgrade: yes
harden-large-queries: yes
harden-short-bufsize: yes
# Privacy
use-caps-for-id: yes # Spoof protection by randomising capitalisation
rrset-roundrobin: yes
qname-minimisation: yes
minimal-responses: yes
hide-identity: yes
identity: "Server" # Purposefully a dummy identity name
hide-version: yes
# Optimisations
msg-cache-slabs: 8
rrset-cache-slabs: 8
infra-cache-slabs: 8
key-cache-slabs: 8
# Caching
cache-min-ttl: 300
cache-max-ttl: 86400
serve-expired: yes
neg-cache-size: 4M
prefetch: yes
prefetch-key: yes
msg-cache-size: 128m
rrset-cache-size: 256m
root-hints: /etc/unbound/root.hints
auto-trust-anchor-file: /etc/unbound/root.key
include: /etc/unbound/a-records.conf
The whole point of raising the TTL to a day or week is to reduce the amount of queries. It obviously won’t make a difference if you create records for all IPs in the subnet and use a TTL of 1 hour.
The other thing you may want to try is to set the TTL for NXDOMAIN to a day or week. As I am not using unbound, my google-fu is the same as yours.
mail2rst
probably something you could raise as question with AGH guys https://github.com/AdguardTeam/AdGuardHome/issues and/or Unbound https://github.com/NLnetLabs/unbound/issues