Jump to content



Photo

DNS problems

Answered Go to the full post

  • Please log in to reply
20 replies to this topic

#16 +BudMan

BudMan

    Neowinian Senior

  • Tech Issues Solved: 90
  • Joined: 04-July 02
  • Location: Schaumburg, IL
  • OS: Win7, Vista, 2k3, 2k8, XP, Linux, FreeBSD, OSX, etc. etc.

Posted 20 February 2014 - 17:06

see my edited post above with screenshot




#17 OP +riahc3

riahc3

    Neowin's most indecisive member

  • Tech Issues Solved: 11
  • Joined: 09-April 03
  • Location: Spain
  • OS: Windows 7
  • Phone: HTC Desire Z

Posted 20 February 2014 - 17:10

Hello,

Not blocked from dell, but blocked from using dell.com ns -- maybe you should use dell.courntrybased tld for where your located?
 
Try doing query direct to the IPs I listed for their nameservers..  They are clearly answering, if you can not reach them then your being blocked, your isp is blocking them or there is a network issue in your path too them.
 
Let me fire up my wins server VM that has dns installed and will show you.  BRB
 
edit: Ok took a couple of minutes didn't have dns role installed - forgot I redid this 2k8r2 server the other day.
 
So here you go - right click the server and pick properties
 
attachicon.gifforwarders-condforwarders.png
 
So you can see from properties where the forwarders are setup, I pointed it to my pfsense box.  And setup a specific forwarder for dell.com that will ask 8.8.8.8 vs my pfsense box.
 
your running what SBS 2008?  Should be the same!

WS2003 SBS.

#18 OP +riahc3

riahc3

    Neowin's most indecisive member

  • Tech Issues Solved: 11
  • Joined: 09-April 03
  • Location: Spain
  • OS: Windows 7
  • Phone: HTC Desire Z

Posted 20 February 2014 - 17:23

Hello,

dns.png

Best screenshot I could give you BudMan, sorry...

#19 OP +riahc3

riahc3

    Neowin's most indecisive member

  • Tech Issues Solved: 11
  • Joined: 09-April 03
  • Location: Spain
  • OS: Windows 7
  • Phone: HTC Desire Z

Posted 20 February 2014 - 17:28

Hello,

fix.png

Sure, that fixes the problem but really is it any different than pushing a additional DNS server thru DHCP?

#20 +BudMan

BudMan

    Neowinian Senior

  • Tech Issues Solved: 90
  • Joined: 04-July 02
  • Location: Schaumburg, IL
  • OS: Win7, Vista, 2k3, 2k8, XP, Linux, FreeBSD, OSX, etc. etc.

Posted 20 February 2014 - 17:50

Yes its COMPLETELY different, your client will never go ask 8.8.8.8 directly for anything - the only time 8.8.8.8 be asked in your case is for DELL.com when somebody asked your AD dns for it.  And your AD nameserver will send the query to 8.8.8.8 not your client.

 

If you just put it on the client he might ask 8.8.8.8 for your AD info, which is not a good security practice for starters and second depending on what gets returned, say NX which should be the correct response your client would say ok that record must not exist, and would never go ask your AD for it.  And now you can have issues with your client resolving your own local resources because they are asking a public dns for it and getting told it doesn't exist NXDOMAIN

 

All dns queries from any box on your network, should ONLY ask your AD dns for anything related to dns.. Do you want your client to ask google dns for the PTR of 192.168.100.x ??

 

Now normally only forwarding to your router in your AD would be fine for stuff that your AD dns is not authoritative for.  But in this case it is having a problem resolving a specific domain, so you want to forward that specific domain queries to something special that does not have the issue.  Another use for this would be if say you had another nameserver that was authoritative for a non public domain like somedomain.local that was not housed on your AD dns - you could setup AD to know which nameserver to ask for that special domain.

 

My only language is english, could you translate what that says exactly - are you forwarding normally to your router, and only dell.com goes to 8.8.8.8?  Or are you asking roots? Did that actually fix your problem?

 

edit:  From a typical security stance you would never want queries even for your local domains or fqdn of your local hosts to be sent outside your network.  Nor would you want PTR queries for your local network/rfc1918 address space to go outside your network.  Secondly its pointless to let it happen since nothing on the outside of your network is going to be able to resolve it anyway - so your just wasting bandwidth and time sending the queries out in the first place.

 

The limiting of what clients can use for dns, also provides you another way of blocking sites you don't what your clients to get to if that is something you want to do.  For example if your clients are only doing queries to your dns, you could setup your dns to be authoritative for say playboy.com - not your users would not be able to query for the IP to go to for that domain and not able to browse that domain, etc. etc..

 

Normally only specific DNS on your domain can even query outbound on dns both tcp/udp - or users could use that port to tunnel out of your network to something else listening on that port.  In a normal business setup either clients are limited to what ports they can leave your network to say http/https/ftp - or better yet you have a proxy on your network that is the only thing that can talk outbound from your network on web ports, etc.  Expect for special use cases where the proxy doesn't work, where you limit to specific IPs - say if client needs to directly vpn to a customer network, you might allow outbound traffic from your clients to the specific IP and port for that special vpn connection directly out your firewall.



#21 OP +riahc3

riahc3

    Neowin's most indecisive member

  • Tech Issues Solved: 11
  • Joined: 09-April 03
  • Location: Spain
  • OS: Windows 7
  • Phone: HTC Desire Z

Posted 20 February 2014 - 22:11

Hello,

Yes its COMPLETELY different, your client will never go ask 8.8.8.8 directly for anything - the only time 8.8.8.8 be asked in your case is for DELL.com when somebody asked your AD dns for it.  And your AD nameserver will send the query to 8.8.8.8 not your client.

Understood :)
 

If you just put it on the client he might ask 8.8.8.8 for your AD info, which is not a good security practice for starters and second depending on what gets returned, say NX which should be the correct response your client would say ok that record must not exist, and would never go ask your AD for it.  And now you can have issues with your client resolving your own local resources because they are asking a public dns for it and getting told it doesn't exist NXDOMAIN

Here we only use AD for auth; There is no intranet or anything that need to be resolved internally via DNS. We used to use it as a NAS too but it got outgrown and now is in a standalone box. Its a shame because this (PowerEdge) is consuming A LOT of power.

Do you want your client to ask google dns for the PTR of 192.168.100.x ??

No, of course not.
 



My only language is english, could you translate what that says exactly - are you forwarding normally to your router, and only dell.com goes to 8.8.8.8?  Or are you asking roots? Did that actually fix your problem?

I will try my best:

The forwarders are servers that can resolve DNS querys that this server cannot reply. Resend the name querys in the following DNS domains.

DNS domains:
All other DNS domains
dell.com

To add a forward, select a DNS domain, write the IP of the forwarder below and click on add (Agregar)

List of IP address of the forwarder of the selected domain:

8.8.8.8

Maxiumum seconds until waiting on the sending of querys (rough translation):
5

Do not use recursive lookup for this domain [Checkbox]




I hope that clears it up :) And yes, this indeed did fix my problem and according to the logic you put forward, it seems the best way to clear it up.



edit:  From a typical security stance you would never want queries even for your local domains or fqdn of your local hosts to be sent outside your network.  Nor would you want PTR queries for your local network/rfc1918 address space to go outside your network.  Secondly its pointless to let it happen since nothing on the outside of your network is going to be able to resolve it anyway - so your just wasting bandwidth and time sending the queries out in the first place.

I imagine you are talking about the 10.x.x.x address; I agree from a security standpoint this might not be the best idea but on the client side, he does have to have a OpenVPN certificate generated by me and that certificate can be revoked


The limiting of what clients can use for dns, also provides you another way of blocking sites you don't what your clients to get to if that is something you want to do.  For example if your clients are only doing queries to your dns, you could setup your dns to be authoritative for say playboy.com - not your users would not be able to query for the IP to go to for that domain and not able to browse that domain, etc. etc..

Nah, not intrested in blocking. This AD like I mentioned does basically nothing.
 


Normally only specific DNS on your domain can even query outbound on dns both tcp/udp - or users could use that port to tunnel out of your network to something else listening on that port.  In a normal business setup either clients are limited to what ports they can leave your network to say http/https/ftp - or better yet you have a proxy on your network that is the only thing that can talk outbound from your network on web ports, etc.  Expect for special use cases where the proxy doesn't work, where you limit to specific IPs - say if client needs to directly vpn to a customer network, you might allow outbound traffic from your clients to the specific IP and port for that special vpn connection directly out your firewall.

Since we are a small business, outward connections are unlimited. Inward connections are obviously all blocked by the firewall.

Thank you for your help as always.