Hikvision ntp issue

[Tolting Colt Acres]

I recently set up PiHole on my network. Reviewing the logs, I noticed my cameras, which were configured to use ntp (pool.ntp.org) were spamming the dns server every few seconds.

going to one of the cameras, I pull up the Time Settings page and verified my settings:


I had set this up years ago in my cameras, I use pool.ntp.org on all my servers on my network, and for my other machines, it works just fine...



when I click on the "test" button, so ntp seems to be fine. Yet, according to my dns logs:



the cameras are spamming the DNS server every few seconds to resolve addresses.

I'm guessing this has something to do with IPv6, which is returning NODATA, and thus (perhaps) causing the cameras to repeatedly re-query the DNS server attempting to get an AAAA record.

Since there does not appear to be a way to disable IPV6 on the cameras, the only solution would appear to be to hard-code an ip address for an ntp server, which of course defeats the entire purpose of using an ntp pool....

 

[watchful_ip]

Run a local NTPD server on the Pi-hole server and point your cameras at that?

That's what I do

 

[Tolting Colt Acres]

yeah... already did that. Reconfigured chronyd on my linux router to act as an ntp server. added a CNAME entry to my internal dns server to point ntp.toltingcolt.local to my router (gateway.toltingcolt.local) @ 192.168.254.254.

the cameras still spam the hell out of the dns server trying to resolve an A and AAAA address for ntp.toltingcolt.local now.

 

[SpacemanSpiff]

yeah... already did that. Reconfigured chronyd on my linux router to act as an ntp server. added a CNAME entry to my internal dns server to point ntp.toltingcolt.local to my router (gateway.toltingcolt.local) @ 192.168.254.254.

the cameras still spam the hell out of the dns server trying to resolve an A and AAAA address for ntp.toltingcolt.local now.

Been a while since doing this type of deed. Seeing as it is your internal network, would it help to use IP based NTP entries on the cams/recorder instead of DNS to keep the chatter down?

 

[Tolting Colt Acres]

did that too. At the moment I'm logging NTP requests via iptables to see exactly how much NTP traffic I'm getting.

For folks who have NTP set up on their cameras, they may likewise be slamming their DNS server with requests and simply not know it.

 

[SpacemanSpiff]

did that too. At the moment I'm logging NTP requests via iptables to see exactly how much NTP traffic I'm getting.

For folks who have NTP set up on their cameras, they may likewise be slamming their DNS server with requests and simply not know it.

Yep... cams are chatty, all the more reason to keep 'em locked up on their own network. Let us know your capture results, would be interested to see the difference between DNS and IP requests for NTP

 

[watchful_ip]

Same - I use the IP of my NTP server and not the dns.

The cameras don't have valid DNS set.

 

[SpacemanSpiff]

...
The cameras don't have valid DNS set.

^^^^
+1

 

[Tolting Colt Acres]

Well, the reason for hammering DNS is the damn cameras make an NTP request every 10 seconds... so if you use dns resolution, you're going to not only get a dns request every 10 seconds but a ntp request every 10 seconds....

Oct 12 14:43:01 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=24733 DF PROTO=UDP SPT=60102 DPT=123 LEN=56
Oct 12 14:43:11 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=25318 DF PROTO=UDP SPT=45822 DPT=123 LEN=56
Oct 12 14:43:22 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=25654 DF PROTO=UDP SPT=46879 DPT=123 LEN=56
Oct 12 14:43:32 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=26570 DF PROTO=UDP SPT=33233 DPT=123 LEN=56
Oct 12 14:43:42 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=27212 DF PROTO=UDP SPT=55819 DPT=123 LEN=56
Oct 12 14:43:52 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=27260 DF PROTO=UDP SPT=37216 DPT=123 LEN=56
Oct 12 14:44:02 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=27765 DF PROTO=UDP SPT=36754 DPT=123 LEN=56
Oct 12 14:44:12 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=28315 DF PROTO=UDP SPT=42508 DPT=123 LEN=56
Oct 12 14:44:22 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=28721 DF PROTO=UDP SPT=48393 DPT=123 LEN=56
Oct 12 14:44:32 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=28802 DF PROTO=UDP SPT=37353 DPT=123 LEN=56
Oct 12 14:44:42 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=29401 DF PROTO=UDP SPT=39035 DPT=123 LEN=56
Oct 12 14:44:52 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=30353 DF PROTO=UDP SPT=50147 DPT=123 LEN=56
Oct 12 14:45:02 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=30666 DF PROTO=UDP SPT=51200 DPT=123 LEN=56
Oct 12 14:45:12 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=31130 DF PROTO=UDP SPT=55923 DPT=123 LEN=56
Oct 12 14:45:22 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=31648 DF PROTO=UDP SPT=33676 DPT=123 LEN=56
Oct 12 14:45:32 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=31828 DF PROTO=UDP SPT=39768 DPT=123 LEN=56
Oct 12 14:45:42 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=32283 DF PROTO=UDP SPT=35754 DPT=123 LEN=56
Oct 12 14:45:52 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=32408 DF PROTO=UDP SPT=49133 DPT=123 LEN=56
Oct 12 14:46:02 gateway kernel: NTP:IN=enp2s0 OUT= MAC=00:01:2e:83:d1:e5:ec:c8:9c:1a:fd:5c:08:00 SRC=192.168.10.240 DST=192.168.254.254 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=32508 DF PROTO=UDP SPT=35932 DPT=123 LEN=56

 

[SpacemanSpiff]

@Tolting Colt Acres, just curious, what is your compelling desire to maintain DNS on your cam settings and their respective network?

 

[Tolting Colt Acres]

@Tolting Colt Acres, just curious, what is your compelling desire to maintain DNS on your cam settings and their respective network?

The output from my cameras has been used in several court cases, including criminal cases. An accurate timestamp is essential. Originally when they were configured, I wasn't using an internal ntp server, they were just set to resolve against the public ntp pool. It was only after setting up pihole did I notice the frequent DNS requests from the cameras, which led to this thread.

 

[Mike A.]

Since you have the internal NTP server now the simple solution would be to just use the IP address instead?

Doesn't answer why the cams do it but these things kind of do what they do regardless in some cases. Using the IP, I don't see any unusually frequent requests from my Hikvision cams in my NTP server logs or in PiHole (since not resolving anything). Obviously that could be different for other cams/firmware. Some of mine do lots of other odd stuff like that no matter how things are set.