[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1263
  • Last Modified:

DNS Forwarders don't work?

Quick question for the DNS elites!  Using an Active Directory Domain Controller, I set up a DNS Server.  I configured the zones for our local domain fine as local domain queries work perfectly well.  However, where I'm running into difficulty are WAN requests.  I have the Forwarders set up to my ISP's.  I know they work because when I do an "nslookup www.domain.com ISPDNSsvr", it works fine.  I've been using the ISP's DNS servers in addition to the local DNS Servers in the DHCP info so it doesn't hold people's work up in the meantime.  Obviously this is bad because after awhile people's computers grind to a halt.

There are no errors in the DNS event log, so why aren't the Forwarders working?  Is it because of the firewall?  I have a Nokia IPSec firewall, and it looks like there aren't any settings.  I setup a policy in the CheckPoint software to send DNS queries to the server - Am I missing something?
0
Core-D
Asked:
Core-D
  • 9
  • 8
  • 3
  • +1
2 Solutions
 
Chris DentPowerShell DeveloperCommented:

Are you sure the ISPs DNS supports recursive queries? This is required for Forwarders to function.

The nslookup command you used above requests the address details directly from your ISPs DNS not via your local DNS so doesn't really establish whether it does or not.

So, could you try "nslookup www.domain.com" for any public domain and see if that gets a response.

If the ISPs DNS doesn't support recursive queries then you can either use Root Hints (full lookup) or find a DNS that does.

All making sense?
0
 
ikm7176Commented:
if you have NOKIA firewal installed with checkpoint. create a rule for your DNS server and allow the DNS ports (i.e TCP 53 and UDP 53). Unless you open these ports for your DNS server, your requests will not bypass the Firewall. These Ports are predifined in your checkpoint software

open your smart dashboard, and login to your checkpoint
Under security tab create a rule for your DNS server as source and ANY as destination
Under services cell rt click- Add and select DNS
Under action select allow

hope this helps you!
0
 
Core-DAuthor Commented:
This absolutely makes sense, so I tried deleted those DNS Servers and tried another two I found for the forward.  Still no dice.  So this is either of two things:

1.  The other DNS servers do not support recursive queries
2.  My queries are being blocked by the Firewall

And as per the Root Hints, I would very much like to configure these, but for lack of a better word, I'd like a 'hint'.  Any advice on this would be greatly appreciate.  And a special thank you to Chris-Dent for helping me learn more.  Keep the tips coming please!
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
Core-DAuthor Commented:
IKM -

Great advice, but ironically I already tried this!  When I finished, I clicked Policy, Install Database... <- Did I miss something?  Thanks for the tip, I really need help with this!
0
 
Chris DentPowerShell DeveloperCommented:

For Root Hints all you have to do is add a Rule to your Firewall that lets your DNS out on Port 53:

Source: Server Computer Object
Destination: Any
Port: 53 - This is set up, by default, as one of the items in the services list on Checkpoint Firewalls

ikm7176's directions should work for that :)

The Root Hints file on your DNS contains a list of the main Root Server (a.root-servers.net - m.root-servers.net) and their IP Addresses. These servers provide the directions to the next step - the Top Level Domain Servers which eventually point to the server that owns a domain but, in effect, they know everything.

The file itself is included as part of the default installation of DNS, and this is the method that will be used unless you either have a zone called "." (that is, make yourself a Root Server), or configure Forwarders.

With Forwarders configured, instead of asking the Root Servers you ask your ISPs DNS if it knows the answer (via a cached query), if not it sets off and finds the answer for you. A recursive query in other words.

So...

1. Check your server has outbound access on port 53, to either everything or the server you're forwarding requests to.

2. Check if your DNS has a Forward Lookup Zone called "." - if so delete it.

3. Under the Properties for the DNS Server confirm that the Root Hints tab contains a list and isn't greyed out.

4. Try NSLookup again

See how that lot goes :)
0
 
ikm7176Commented:
where did you configured your forwarders IP address

If you have a policy already defined in the firewall. Make sure that your DNS server is having connectivity to your firewall (i.e gateway should be your firewall's IP address) - i hope you already checked this !

I dont know which version of dashboard you are running , i have "SmartDashboard with hotfix 0.010 and Build 1" and i have setup my forwarders in the DNS server forwarders TAB.
Fefined the policy in smartdashboard and clicked Install policies with INSTALL ON = MY FIREWALL OBJECT selected

Did your firewall verified the policy correctly ?

0
 
Core-DAuthor Commented:
OK -

Firewall:        Policy is installed with no Errors on <my firewall object>
DNS Server:   There was no "." and the Root Hints tab contains a list.  A list of two things -
j.root-servers.net.                                 [192.58.128.30]
a.root-servers.net.                                [192.41.0.4]

* Now I'm no expert on root hints, but there should probably be more than two entries am I right?  Where did I go wrong and what can I do to fix it! *
0
 
crissandCommented:
Don't announce the ISP's dns to workstations. They must be capable to use your dns to resolve queries.

Now, about root hints and forwarders. If you use forwarders, the speed of resolving addresses is bigger than using root hints. If your ISP's dns doesn't resolve your queries, try enabling "Don't use recursion" in the forwarders section of the DNS.

Is nslookup resolving queries when run on workstations? There must be a non-authoritatve answer for any external address.
0
 
Chris DentPowerShell DeveloperCommented:

Yes, there are normally a few more than that...

Here's the Microsoft Article on fixing it:

http://support.microsoft.com/kb/249868/EN-US/

Run through that (it won't take long) and see if it shows a few more, then it's back to nslookup once more.
0
 
Chris DentPowerShell DeveloperCommented:

Crissand is correct though, you don't want those ISPs DNS servers in the client config - although why they're there at the moment is clear :)

And Root Hints are slower than Forwarders - but I always prefer them because I don't like relying on ISPs DNS - just my own opinion though.

Still, it would be a really good idea to get them working, even if just to verify that your DNS is functioning correctly and you go back to Forwarders afterwards.
0
 
Core-DAuthor Commented:
OK, Root Hints are now in place.  Thank you very much for the article Chris-Dent.  However, nslookups still fail.  There's something missing here and if anyone has any idea what it is please let me know.  Thanks everyone for their great suggestions - I've tried every last one of them so please keep them coming!  This is so important for me to get running.
0
 
crissandCommented:
What's the message from nslookup. When it starts, it shows the correct dns? What is the answer of nslookup if you type the name of a workstation from the local network? Can it resolve the name to the address? What the response when you type an address from the local network? Is is resolved to the name of the workstation?

nslookup

>>name-of-workstation

>>address-of-workstation

>>external-name

>>external-address (if you know one)

Are the workstations joined to the domain?
0
 
Core-DAuthor Commented:
When it starts, it shows the full Active Directory Machine name of the DNS Server, followed by the address.

>>name-of-workstation - Works fine

>>address-of-workstation - Works fine (set up a reverse look up zone)

>>external-name - Time out

>>external-address (if you know one) - Time out

All the workstations are joined to the domain.  
0
 
Chris DentPowerShell DeveloperCommented:

Another suggestion, in addtion to those from Crissand above.

Can you run this lot from the server (C:\> and > are just to represent the prompt it gives you):

C:\> nslookup
> server <IP Address of ISPs DNS>
www.google.com

If it times out the request there then traffic on Port 53 might not be allowed through for the server - it will use your ISPs DNS to perform the query. Worth testing out to cover the possibility. It should work from what you've posted earlier though.

Also try:

C:\> nslookup
> a.root-servers.net

To get the address for that server, then:

C:\> ping a.root-servers.net

To verify that IP Traffic is allowed to that server from yours.

Before you test any external addresses it might be worth flushing the DNS Cache on your server with:

dnscmd /ClearCache

Then perhaps try:

C:\> nslookup
www.experts-exchange.com

Name: experts-exchange.com
Address: 64.156.132.140
Aliases: www.experts-exchange.com

And:

> 64.156.132.140

Name: www-level3.experts-exchange.com
Address: 64.156.132.140
Aliases: 140.132.156.64.in-addr.arpa

As the external address to test.
0
 
Chris DentPowerShell DeveloperCommented:

Ahh ignore the external tests in mine then, no point if they time out.

But still try the nslookup via the ISPs DNS from the server, and the lookup and ping for a.root-servers.net.
0
 
ikm7176Commented:
Restarting the firewall would not solve your problem. login to smartview tracker of your checkpoint and trace the connections attempted by your DNS server. You need to make sure that  Domain-udp service is not blocked by your Checkpoint software .
Hope this helps you!
0
 
crissandCommented:
The result you obtained (time-out) was without forwarders, I think. Now input the forwarder as the ISP's DNS address, and try again the test.
0
 
Core-DAuthor Commented:
ikm7176, you hit the nail right on the head.  It is blocking udp traffic in a big way.  What can I do to stop this?
0
 
Chris DentPowerShell DeveloperCommented:

Add a node in Checkpoint rules for your server (with the internal IP).
If you use Forwarders add another node with the external address of the server you forward to.

Then it should be something like:

Source: Your Server node
Destination: Any or the Forwarder Node
Traffic: Domain-UDP
Log: Probably not necessary

That should be all really - depends a little on your current rules.
0
 
Core-DAuthor Commented:
Chris-Dent - Thank you for your post!  In my Checkpoint rules, I have a node set up for:

Source - DNS Server (Host added)
Destination - Any
Service - DNS
Action - Accept

I thought that by having *Any destination it should work.  Is there something more I need to configure?  Do I need to make a host for every Forwarder and Root Hint?  Or shouldn't this just work?
0
 
Core-DAuthor Commented:
The exact error for the Drop domain-udp is Illegal Packet Length, just in case I was being too vague with the UDP traffic error.  Thanks everyone!
0
 
Chris DentPowerShell DeveloperCommented:

Now that one I'm not sure about, might be a good idea to wait for ikm7176 and see if he knows ;)
0
 
Core-DAuthor Commented:
Ok EVERYONE!  I got it working.  One thing for everyone who uses CheckPoint AND Active Directory DNS Servers should keep in mind:

Under SmartDefense Configuration in your SmartDashboard, make sure under the DNS tab that UDP Protocol enforcement is Checked Off.  It is highly recommended in a CheckPoint book I read not to enable this and the second I disabled this DNS started working.  Thank you to everyone!
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 9
  • 8
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now