Please follow the below template, it will help us to help you!
Expected Behaviour:
When looking up an IP/Hostname that has a static DHCP lease, for it to resolve properly
Actual Behaviour:
Server: pi-hole
Address: 192.168.2.2
Name: device1.local
Address: 192.168.2.184
C:\Users\user>nslookup device1.local
Server: pi-hole
Address: 192.168.2.2
Name: device1.local
Address: 192.168.2.184
C:\Users\user>nslookup device2.local
Server: pi-hole
Address: 192.168.2.2
Name: device2.local
Address: 192.168.2.7
C:\Users\user>nslookup 192.168.2.7
Server: pi-hole
Address: 192.168.2.2
*** pi-hole can't find 192.168.2.7: Non-existent domain
C:\Users\user>nslookup 192.168.2.2
Server: pi-hole
Address: 192.168.2.2
Name: pi-hole
Address: 192.168.2.2
Debug Token:
y8uq29pxbg
Device1 is a DHCP Auto Address
Device2 is a DHCP Static Address
If I use an automatically assigned DHCP address it works fine in both reverse and forward lookups. If I use a static DHCP address, it works fine only in one direction. This is not necessarily problematic, but it would be helpful to lookup in both direction0s.
You can't dig an IP address, you need to dig the reverse, the ARPA record for the IP address. You're asking DNS to give you the IP address of the IP address.
Try dig <device2name> @ 192.168.2.2 and then dig -x <device2ip> @192.168.2.2 and the first should give you the IP back and the second should give you back the ARPA domain name of the IP address.
True, but using nslookup should still return the hostname when doing a lookup for the IP Address. Even when using DIG it still fails as shown below:
user@device2:~/tmp/configs$ dig device2.local
; <<>> DiG 9.10.3-P4-Ubuntu <<>> device2.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9673
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;device2.local. IN A
;; ANSWER SECTION:
device2.local. 0 IN A 192.168.2.7
;; Query time: 2 msec
;; SERVER: 192.168.2.2#53(192.168.2.2)
;; WHEN: Fri Jan 26 23:32:25 PST 2018
;; MSG SIZE rcvd: 59
user@device2:~/tmp/configs$ dig -x 192.168.2.7
; <<>> DiG 9.10.3-P4-Ubuntu <<>> -x 192.168.2.7
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1674
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;7.2.168.192.in-addr.arpa. IN PTR
;; Query time: 9 msec
;; SERVER: 192.168.2.2#53(192.168.2.2)
;; WHEN: Fri Jan 26 23:32:38 PST 2018
;; MSG SIZE rcvd: 53
Not to mention - using a static lease seems to not be completely responsive. Half the time it works, the other half it just doesn't respond.
This is only about ~10 minutes away from each other and the device has not shutdown or restarted since the initial nslookup was performed.
Server: pi-hole
Address: 192.168.2.2
Name: esxi.local
Address: 192.168.2.6
C:\Users\andrew>nslookup esxi.local
Server: pi-hole
Address: 192.168.2.2
*** pi-hole can't find esxi.local: Non-existent domain
Well I learned something new, nslookup on an IP address will try to pull the PTR record for the IP if no other command line arguments are given. I don't use that utility all that often, never knew it could do that.
As for the DHCP lease, I'm not sure if we set the PTR records or if dnsmasq automatically sets the PTR records for leases but this would be something that is configured on the dnsmasq level. I'll do some research on it and find out.