Hi,
Think not really a Beta 6.0 question, but felt better to post the question here as in others the answer could be go to Beta 6.0 with your question.
So...
Today I decided to change the way my IP/PoE security cameras are connected to the network.
Pi-hole is the DHCP-server and the cameras are each handed out an static address as per below example.
ec:71:db:<redacted>,192.168.2.222,FrontDoorHigh
From one device I get 100s of error messages:
From Query Log:
2024-03-20 20:05:28 N/A . frontdoorhigh.eth2 10.6 ms
Query received on: 2024-03-20 20:05:28.302 Client: frontdoorhigh.eth2 (192.168.2.222) DNSSEC status: INSECURE Query Status: Forwarded to 1.1.1.1#53 Reply: NOTIMP Database ID: 419749
From Pi-hole.log:
2024-03-20 20:05:27.366 forwarded . to 1.1.1.1
2024-03-20 20:05:27.376 validation result is INSECURE
2024-03-20 20:05:27.377 reply error is not implemented
2024-03-20 20:05:27.378 query[type=65535] . from 192.168.2.222
2024-03-20 20:05:27.379 forwarded . to 1.1.1.1
2024-03-20 20:05:27.388 validation result is INSECURE
2024-03-20 20:05:27.389 reply error is not implemented
2024-03-20 20:05:27.390 query[type=65535] . from 192.168.2.222
2024-03-20 20:05:27.391 forwarded . to 1.1.1.1
2024-03-20 20:05:27.402 validation result is INSECURE
2024-03-20 20:05:27.402 reply error is not implemented
Just wonder why and perhaps how to fix, out of all the devices it is only this particular device that keeps doing this.
Camera configuration same on all the cameras.
Camera reset a couple of times.
This is not a Pi-hole issue, regardless of version:
That camera of yours is sending a DNS query for RR type 65535 (and for the root servers at '.').
That RR type is not assigned by IANA - in fact, it is reserved, so it's not even legit for private use, see Domain Name System (DNS) Parameters.
Consequently, 1.1.1.1 is answering that request with RCODE 4 - not implemented.
I can't seriously guess why your camera would send such a query for a non-existing RR type, but this looks like a bug in your camera's firmware.
You could consider to consult its manufacturer's support (Reolink?) for advice.
Just to give an update from my exchanges with the manufacture (Reolink).
After several email exchanges with Reolink Support then they (Reolink) have concluded:
I have once again relayed the specific symptoms of this issue to our research and development team and requested them to carefully review the screenshots you provided. They have confirmed that this is normal DNS request behavior and not a security issue such as a network attack. This is a result of our current DHCP request strategy, and we will strive to optimize the strategy in the future to avoid excessive invalid DHCP requests.
I have blocked for all said request and for access to the Internet.
This is not a technically very meaningful response - do they try to explain invalid DNS requests with DHCP requests when the latter is an entirely different protocol running on different ports?...
