Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
barakh
Explorer

Domain resolving error. Check DNS configuration on the gateway (0)

hello

we started receiving the following alerts:

Domain resolving error. Check DNS configuration on the gateway (0)

 
 

1.PNG

 

2.PNG

 

 

 

 

 

 

 

 

 

 

I found only one sk about the topic sk120558 But it doesn't seem to be related to the issue.

we have cluster of Check Point 23500 appliance

the version is R80.30 jumbo take 155

we run nslookup from the gw and its look like fine 

# nslookup google.co.il
Server: x.x.x.x
Address: x.x.x.x#53

we also run dig command from gateway

#dig google.com

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-25.P1.11.cp993000013 <<>> google.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31783
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 26 IN A 172.217.171.238

;; Query time: 1 msec
;; SERVER: x.x.x.x#53(IPv4 address of dns server)
;; WHEN: Sun Jun 14 18:37:35 2020
;; MSG SIZE rcvd: 44

 

I would like for advice on what to do to stop receiving these alerts

 

0 Kudos
8 Replies
_Val_
Admin
Admin

You masked this too well. It is hard to see which layer is complaining. 🙂

Please clarify if:

1. you are using any of domain objects

2. using proxy on your GW

barakh
Explorer

we are using updatable objects not domain objects

No proxy is used

0 Kudos
johnnyringo
Advisor

I just encountered this.  We are using Domain objects, and they were working fine until last week, when I had to undo Management vs. Data Plane Separation  in order to get syslogging working via the Mgmt interface.

The root cause was the Network Management -> Topology settings.  It appears that whichever interface is being egressed to reach the DNS server must have "Leads to -> Network defined by Routes" in order to reach the DNS server at the data plane level.

When doing a ping, dig, or nslookup via CLI, the Topology settings are not applicable, which explains why those tests work.  

aboo008
Participant

I am having the same issue. A while back working with CP TAC they had asked me to do a get interfaces to resolve a separate issue but since that time onwards we had some wierd issues. I was told to update our version now 80.10 with latest Jumbo Fix. 

Anyone found an exact fix to this problem. Top comment seems to be on point but don' understand what the solution was. Thanks for any help. 

0 Kudos
Daniel_Kavan
Advisor

I am using a domain object actually, zoom.us on this gw and this is the only gw having this issue.   I guess I'll just continue to ignore the error/alert, since we are using that object.

RE: Domain resolving error. Check DNS configuration on the gateway.  

Version: R81.10 JHF55

0 Kudos
Kaspars_Zibarts
Employee Employee
Employee

One thing you should check is that GW can resolve DNS names using both UDP and TCP. Some larger DNS responses that cannot be pushed in single UDP packet will trigger fallback to TCP protocol. Depending on the FW setup TCP lookups might be dropped. And that will result in error above

Daniel_Kavan
Advisor

Thanks for the reply.  It is interesting.   

nc -z -v 1.1.1.1 53 responds

nc -z -v -u 1.1.1.1 53  = no response.

Other systems can get to DNS (UDP) for some reason the firewall can't.  I'm getting out, nothing coming back.  Looking into it...

 

0 Kudos
Kaspars_Zibarts
Employee Employee
Employee

I would probably put little more effort into it and try actual packet capture for DNS lookups from gateway itself as error itself indicates that gateway is failing to get DNS responses for FQDN object lookups

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events