DNS trap always shows same domain

[kadar2]

Hello all,

A few weeks ago, a suspicious communication towards the domain “4s.pm” was identified by Anti-Virus blade and DNS trap was successfully enforced.

Since then, what we notice and we can not explain is the fact that if we search for “DNS Trap” all the results refer as destination “4s.pm” (screenshot 1). This is weird and most possibly false because if we randomly open one of these logs (Screenshot 2), in the forensics section the actual domain is referred and it is not “4s.pm”.

Can somebody help us understand the behavior?

[PhoneBoy]

Refer to how the DNS Trap works here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
The IP address listed (62.0.58.94) is the default configuration for DNS Trap and is expected behavior.

[kadar2]

Hello PhoneBoy,

the question isn't related to the IP 62.0.58.94, which is the default DNS trap.

We do not have any actual traffic that is trying to reach 4s.pm (only one incident about a month ago). No DNS requests towards 4s.pm are logged in our DNS servers. So it is confusing to see this domain in the DNS trap logs. As you can see in the "screenshot2" the forensics details --> resource refers to a totally different domain. So why isn't the actual domain (digitaloceans.com in our example) translated to 62.0.58.94?

[Chris_Atkinson · Accepted solution]

If you create a dummy object in your DB (example name: cp-dns-trap) for that IP does it make it clearer in the logs?

Alternatively you can disable object resolution with Ctrl-r or change the DNS trap IP.

Refer also: https://community.checkpoint.com/t5/Management/SMS-log-incorrect-name-resolution/td-p/128459

[kadar2]

We actually opened a TAC case and we are awaiting on feedback.

[Chris_Atkinson]

You can also try adjusting the DNS cache, but that's probably the extent of it.

https://community.checkpoint.com/t5/Management/SMS-log-incorrect-name-resolution/td-p/128459#M31568

[kadar2]

I run into a post somewhere (can't remember exactly where) that said that a cpstop;cpstart on SMS could resolve the issue.

Today we performed a hotfix installation on our SMS and currently we aren't facing the issue with the DNS trap.

Lets hope it fixed it!