- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Why do Hackers Love IoT Devices so Much?
Join our TechTalk on Aug 17, at 5PM CET | 11AM EST
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
sk120558 does not apply - just FYI
problem is as self-explained by the screenshot. please have a look.
it is all fresh R80.40 all-in-one dual-stack infrastructure.
error is just an ALERT not BLOCK/DROP/DENY - just so you know 🙂
see the screen and tell me if you find any clues as I'm struggling to find any
1. DNS resolution works on v4 /both = fwd/rev
2. DNS resolution works on v6 /rev only! wonder why ...
ps. resolution from the gateway nslookup'ing or dig'ing - dig resolves ALL - nslookup resolves v6 only REV not FWD queries!
I think I found the bug chaps! see my screenshot.
Cheers
alright guys, it truns out to be a completely non-CP related problem and after deep-dive (together with @Ilya_Yusupov and others) we have discovered issues with the Microsoft DNS server (aparently Windows 2019 DataCenter DNS server) which was having issues with ZoneTransfers between the RevDSN zones towards and from its partner (2 DNS servers, 1 PRI, 1 SEC for 2 Zones).
errors like this made CP SG feel a little bit of stress and some recursive queries like rev.dns.ip.cn were simply overloading udp/52 socket. it happened and now it all works like charm as I have focused on fixing it last night and played deep-dive with the crap of MS DSN technology 😛
now no alerts are recorded and CP is NOT struggling any longer with DNS recursive queries (IPv6/IPv4).
Bear in mind it all happened in the environment where about you've got BOTH STACKS - IPv4 and IPv6 which coexist for ALL services inc. NAT 624/426 etc.
Cheers to all and happy R80.30 🙂
Exactly the same issue can be found on our customers 5400 R80.40 JT 25 GWs - we have SR#6-0001976805 open for it now...
I have pointed CP to this CheckMates topic - but i would assume someone in the R80.40 team does know of this bug already... Does it show to be cosmetic only in your case ?
Hi @Jerry ,
i saw same in the past while the issue was that TCP DNS was not hit by implied rule and we didn't have explicit TCP DNS rule to allow it.
can you please check if TCP DNS is allowed by your RB?
Thanks,
Ilya
Thanks @Jerry , i will contact you offline to schedule remote.
Expert@cp:0]# nslookup X.ipv6.domain.co *** HOST RESOLVES fine by other devices ***
Server: 1.2.3.4
Address: 1.2.3.4#53
*** Can't find X.ipv6.domain.co: No answer
[Expert@cp:0]# nslookup X.ipv4.domain.co
Server: 1.2.3.4
Address: 1.2.3.4#53
Name: X.ipv4.domain.co
Address: 1.2.3.4
[Expert@cp:0]#
and rev dns v4:
[Expert@cp:0]# nslookup 1.2.3.5
Server: 1.2.3.5
Address: 1.2.3.5 #53
5.3.2.1.in-addr.arpa name = X.ipv4.domain.co.
[Expert@cp:0]#
Thanks @Jerry , i will take it with RnD and will back to you.
Still no feedback in SR#6-0001976805 open for it - strange...
Finally an update in SR#6-0001976805 from CP:
Currently, it doesn't seem a bug but looks more as a failure with the DNS Resolver.
Please follow these steps to restart the DNS resolver:
Run the command # killall wsdnsd
Push policy.
To confirm it is working, please verify the 3 kernel table for resolver
#fw ctl multik print_bl dns_reverse_domains_tbl
#fw ctl multik print_bl dns_reverse_cache_tbl
#fw ctl multik print_bl dns_reverse_unmatched_cache
In case the restart will not solve the alerts of the DNS, please proceed with debugs of
the wsdnsd daemon:
Ilya_Yusupov, any comment ?
@G_W_Albrecht @Jerry thank you guys for the update, i will review the solution with RnD and updated.
@Jerry - if you solved the problem so no need for a remote today i will review the solution with RnD and update here.
@Jerry - no problem.
Any news about this issue ?
alright guys, it truns out to be a completely non-CP related problem and after deep-dive (together with @Ilya_Yusupov and others) we have discovered issues with the Microsoft DNS server (aparently Windows 2019 DataCenter DNS server) which was having issues with ZoneTransfers between the RevDSN zones towards and from its partner (2 DNS servers, 1 PRI, 1 SEC for 2 Zones).
errors like this made CP SG feel a little bit of stress and some recursive queries like rev.dns.ip.cn were simply overloading udp/52 socket. it happened and now it all works like charm as I have focused on fixing it last night and played deep-dive with the crap of MS DSN technology 😛
now no alerts are recorded and CP is NOT struggling any longer with DNS recursive queries (IPv6/IPv4).
Bear in mind it all happened in the environment where about you've got BOTH STACKS - IPv4 and IPv6 which coexist for ALL services inc. NAT 624/426 etc.
Cheers to all and happy R80.30 🙂
I am seeing this on a R80.40 JFH.T48 gateway and Windows Server 2019 DNS - but have only ipv4 enabled. What did you do to fix the 2019 DNS?
I would also like to add that I am seeing this error when the internal DNS server queries the internet forwarder. I'm evening seeing it on ICMP traffic. That does not make any sense.
For me, this started happening after upgrading from R80.30 to R80.40. What changed in regards to DNS between these versions?
Hi @Jerry,
What exactly happen on R80.40? do you still see same issue as we investigate on previous version?
can we do another remote session for investigation it on R80.40?
As mentioned earlier - this is just from NOW on. Unreachable by ipv6 routing are dropped, reachable are allowed but still alerted. this isn't happening on my other Standalone devices under R80.30 (latest take) so only by R80.40 (latest) it is happening. Any clues?
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY