DNS problems


Recommended Posts

Hello,

Im problably doing something stupid and/or idiotic so bear with me here.

I cant seem to reach sites such as Dell community forums and Wikipedia. For some reason, Ive always seen this as a DNS issue because I can ping them and access them via IP.

So I take a look at the AD and its DNS and DHCP settings. Nothing looks out of normal.

Right now, in the DHCP server, I am pushing as DNS server the AD itself and also 10.11.11.16; Why the hell would I do that? I did this as a bandaid because if a client is in the other side of the world, he cant logon to the domain. Now, if the client is in the other side of the world, makes a VPN connection, and tries to login to the domain, it does work as it can resolve the domain server. I am sure there are 10000000s of better ways to do this but another thread (BudMan) :p

Anyways, I really didnt see any logic to it so I said what the hell and I tried pushing the following to my DHCP clients:

AD itself

8.8.8.8

10.11.11.16

In that order, and now it works; Why would it need Google to solve something like Wikipedia? The Gateway is set as my actual Gateway so...

AD is Windows Server 2003 Small Business Server.

Link to comment
Share on other sites

"I am pushing as DNS server the AD itself and also 10.11.11.16;"

 

What is this 10.11.11.16 server?  Is that another server that knows your AD domain?  And authoritative for any other domains you have?

 

Here is the thing if a client is a member of AD, the only dns it should point to is your AD dns - period!!  You are never going to be sure what dns a client asks that is in its listing.  No matter what order you put them in - the client will use an algorithm to determine which dns it uses, based upon if one is slow to answer, be it doesn't answer the query, etc. etc.

 

Your clients that need to resolve AD should only ask your dns that is authoritative for your AD domain - this nameserver should then either forward to outside dns to resolve say dell.com records, or it should directly query the roots, etc.  You can setup specific forwards for specific domains if you want, say if they ask for dell.com it asks 10.11.11.16, if it asks for somethingelse.tld it asks 8.8.8.8, etc.  If you have specific servers that only resolve specific domains. But in general your AD nameservers should just forward queries for stuff its not authoritative for to a public dns - be it the one supplied by your ISP or say google or opendns, etc.

 

Now if your network only allows specific boxes to query outside dns, then your AD nameservers might forward to them, and then they either ask your isp or googledns or roots, etc.  But a client on your network - especially if member of AD should not be listed to query outside dns at all, because googledns is not going to have a freaking clue about your AD..  And from a security point of view you would not want those sorts of queries leaving your network.  Same goes for your PTR queries that every client is going to look up depending on what your doing - there is no way googledns or your ISP is going to know what the PTR for any of your rfc1918 address are..  Your local dns would be the only dns that knows what the PTR for 10.11.11.16 is for example.

 

If you are having issues with resolving dell.com then you need to look to the DNS your AD member is asking and troubleshoot why it can not resolve the domain, you should not be pointing your client to other dns.

Link to comment
Share on other sites

Hello,

"I am pushing as DNS server the AD itself and also 10.11.11.16;"

 

What is this 10.11.11.16 server?  Is that another server that knows your AD domain?  And authoritative for any other domains you have?

10.11.11.16 is the AD server itself when connected to the VPN (OpenVPN server which is another box). So when clients are roaming, they connect to the VPN, and can auth against 10.11.11.16

 

 

Here is the thing if a client is a member of AD, the only dns it should point to is your AD dns - period!!  You are never going to be sure what dns a client asks that is in its listing.  No matter what order you put them in - the client will use an algorithm to determine which dns it uses, based upon if one is slow to answer, be it doesn't answer the query, etc. etc.

The order I put them is because, as you mentioned various times, the clients should always point to the AD as the DNS server. The first DNS, 192.168.100.29, is the AD inside the network, 8.8.8.8 is obvious, and 10.11.11.16 is the AD's IP when connected to the VPN.

 

Your clients that need to resolve AD should only ask your dns that is authoritative for your AD domain

SBS only allows for one autoritvate AD server and besides we are small enough two have only one.

 

- this nameserver should then either forward to outside dns to resolve say dell.com records, or it should directly query the roots, etc.

Since the gateway it set to my router, it should forward it automatically to whatever (outside) DNS I have on my router, correct?

 

You can setup specific forwards for specific domains if you want, say if they ask for dell.com it asks 10.11.11.16, if it asks for somethingelse.tld it asks 8.8.8.8, etc.  If you have specific servers that only resolve specific domains. But in general your AD nameservers should just forward queries for stuff its not authoritative for to a public dns - be it the one supplied by your ISP or say google or opendns, etc.

Im semiconfused on the fact that it can resolve most domains: Neowin, techspot, Facebook, etc.....yet two that come to mind, Dell's forum and Wikipedia it cant. There is also no blocking on these domains or anything.

 

Now if your network only allows specific boxes to query outside dns, then your AD nameservers might forward to them, and then they either ask your isp or googledns or roots, etc.  But a client on your network - especially if member of AD should not be listed to query outside dns at all, because googledns is not going to have a freaking clue about your AD..  And from a security point of view you would not want those sorts of queries leaving your network.  Same goes for your PTR queries that every client is going to look up depending on what your doing - there is no way googledns or your ISP is going to know what the PTR for any of your rfc1918 address are..  Your local dns would be the only dns that knows what the PTR for 10.11.11.16 is for example.

This is not a box specific issue as Ive tested making a VM and joining it to the domain; Those cant access wikipedia and dell's forum either. So it has to be a configuration issue.

 

If you are having issues with resolving dell.com then you need to look to the DNS your AD member is asking and troubleshoot why it can not resolve the domain, you should not be pointing your client to other dns.

tracert (Windows) would be the best way to troubleshoot this, correct?

Ill try to get some tests in and post the results.

BTW, can I change the language per user on WS2003SBS or is that just a W7 ultimate thing? It would make it easier so I can post results and configuration settings :)

Link to comment
Share on other sites

Well your dhcp should only hand out IPs they can get too.. Can clients get to the 10.x address?  I would think you would only hand that out to the vpn clients if that is the IP of your AD dc (dns) when on the vpn.

 

But 8.8.8.8 should not be in there be it the clients are on the local network or vpn'd

 

if your having issues resolving domains, then you need to look to why your nameserver (AD that your clients point to can not resolve it - not point your clients to something other than your AD dns.

 

No tracert has nothing to do with a dns related issue - unless your saying your AD dns server can not get to the dns you are forwarding too or its directly doing queries to roots.  If you say you forward your AD dns to your router to look up stuff when its a fqdn that your AD is not authoritative for - then you need to figure out why your router is not looking up the domains - where does it point to?

 

Your best tools for troubeshooting dns related problems is nslookup or better yet dig, part of the BIND package you can download from ISC, and just install the tools - works just fine on windows based machines.  I use it almost daily.  And one of those tools that every IT person should have access too.

Link to comment
Share on other sites

^ if he wants to forward his router or his AD to those then sure..  But which one would be quicker kind of really pointless since they are anycast addresses..  And just point to the same stuff.

How does Google Public DNS know which data center to send me to?

Google Public DNS uses anycast routing to direct all packets to the closest DNS server. For more information on anycast routing, see the Wikipedia entry.

Link to comment
Share on other sites

Hello,

Well your dhcp should only hand out IPs they can get too.. Can clients get to the 10.x address?

Unless they are connected to the VPN server, no, they cannot. Like I said, its a bandaid to a problem.

I would think you would only hand that out to the vpn clients if that is the IP of your AD dc (dns) when on the vpn.

Well, this may sound strange and like I said my OpenVPN setup can be done thousands of times better but I have two OpenVPN servers running on two different ports. One is internal access and the other is for troubleshooting clients. The troubleshooter can run additional parameters like for example handout IPs. The one for internet access can do nothing as it its that advance AFAIK.

if your having issues resolving domains, then you need to look to why your nameserver (AD that your clients point to can not resolve it - not point your clients to something other than your AD dns.

 

No tracert has nothing to do with a dns related issue - unless your saying your AD dns server can not get to the dns you are forwarding too or its directly doing queries to roots.  If you say you forward your AD dns to your router to look up stuff when its a fqdn that your AD is not authoritative for - then you need to figure out why your router is not looking up the domains - where does it point to?

TVing into my workplace I cant find the exact DNS server my router ZyXEL USG 50 is looking at...might have to take a look at the manual tommorow.

 

Your best tools for troubeshooting dns related problems is nslookup or better yet dig, part of the BIND package you can download from ISC, and just install the tools - works just fine on windows based machines.  I use it almost daily.  And one of those tools that every IT person should have access too.

Will test that out tommorow :) Thank you
Link to comment
Share on other sites

Does not matter if you have 1,2 or 1000 openvpn servers running - why would they be getting the same dhcp scope as your internal clients?  Are you in tap mode?  Why would you not use tun and route their connection and hand them the appropriate IP and info from the openvpn connection?

Link to comment
Share on other sites

Hello,

Back down ( en.community.dell.com ) Tried dig:

C:\Users\user>dig en.community.dell.com

; <<>> DiG 9.9.5-W1 <<>> en.community.dell.com

;; global options: +cmd

;; connection timed out; no servers could be reached

C:\Users\user>dig

; <<>> DiG 9.9.5-W1 <<>>

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31539

;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1280

;; QUESTION SECTION:

;. IN NS

;; ANSWER SECTION:

. 69891 IN NS l.root-servers.net.

. 69891 IN NS a.root-servers.net.

. 69891 IN NS d.root-servers.net.

. 69891 IN NS f.root-servers.net.

. 69891 IN NS e.root-servers.net.

. 69891 IN NS m.root-servers.net.

. 69891 IN NS h.root-servers.net.

. 69891 IN NS b.root-servers.net.

. 69891 IN NS k.root-servers.net.

. 69891 IN NS c.root-servers.net.

. 69891 IN NS i.root-servers.net.

. 69891 IN NS j.root-servers.net.

. 69891 IN NS g.root-servers.net.

;; ADDITIONAL SECTION:

l.root-servers.net. 86400 IN A 199.7.83.42

a.root-servers.net. 86400 IN A 198.41.0.4

d.root-servers.net. 86400 IN A 199.7.91.13

f.root-servers.net. 86400 IN A 192.5.5.241

e.root-servers.net. 86400 IN A 192.203.230.10

h.root-servers.net. 86400 IN A 128.63.2.53

b.root-servers.net. 86400 IN A 192.228.79.201

k.root-servers.net. 86400 IN A 193.0.14.129

c.root-servers.net. 86400 IN A 192.33.4.12

i.root-servers.net. 69891 IN A 192.36.148.17

j.root-servers.net. 86400 IN A 192.58.128.30

g.root-servers.net. 86400 IN A 192.112.36.4

;; Query time: 150 msec

;; SERVER: 192.168.100.29#53(192.168.100.29)

;; WHEN: Thu Feb 20 14:02:45 Hora est?ndar romance 2014

;; MSG SIZE rcvd: 444

C:\Users\user>

192.168.100.29 is my AD server (and DNS)

Link to comment
Share on other sites

Well where do you point for dns where you ran dig?

 

<<>> DiG 9.9.5-W1 <<>> en.community.dell.com
;; global options: +cmd
;; connection timed out; no servers could be reached

 

Say your dns server did not answer you in a timely fashion.  Set a timer to wait longer in dig, so does your AD query roots or forward? 

 

So you can see here

 

; <<>> DiG 9.9.5-W1 <<>> en.community.dell.com                            
;; global options: +cmd                                                   
;; Got answer:                                                            
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50436                 
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1      
                                                                          
;; OPT PSEUDOSECTION:                                                     
; EDNS: version: 0, flags:; udp: 4000                                     
;; QUESTION SECTION:                                                      
;en.community.dell.com.         IN      A                                 
                                                                          
;; ANSWER SECTION:                                                        
en.community.dell.com.  221     IN      CNAME   commweb-ps3.us.dell.com.  
commweb-ps3.us.dell.com. 221    IN      A       143.166.170.97            
                                                                          
;; Query time: 21 msec                                                    
;; SERVER: 192.168.1.253#53(192.168.1.253)                                
;; WHEN: Thu Feb 20 07:51:23 Central Standard Time 2014                   
;; MSG SIZE  rcvd: 95                                                     
                                                                        

 

My pfsense box, which just forwards to my isp comcast and a couple of others responded in 21 ms to that query..  He clearly did not have it cached and went and looked it up from one of its forwarders.

 

Now if I look it up again.

;; QUESTION SECTION:                                                     
;en.community.dell.com.         IN      A                                
                                                                         
;; ANSWER SECTION:                                                       
en.community.dell.com.  132     IN      CNAME   commweb-ps3.us.dell.com.
commweb-ps3.us.dell.com. 132    IN      A       143.166.170.97           
                                                                         
;; Query time: 4 msec                                                    
;; SERVER: 192.168.1.253#53(192.168.1.253)                               
;; WHEN: Thu Feb 20 07:52:52 Central Standard Time 2014                  
;; MSG SIZE  rcvd: 92      

 

Why don't you try looking up something else?  Seems odd to me that it takes your dns 150ms to return the root servers?  But he answered atleast -- so your timeout lookup up the dell records just means he did not find it from who he asks and so why it timed out asking him.. Did you try it again in a second or so?  See if he got an answer by then?  If not you need to move up the chain to see why your having a problem?

 

so you can lookup who the authoritative dns is with a whois

 

 

   Domain Name: DELL.COM
   Registrar: SAFENAMES LTD
   Name Server: NS1.US.DELL.COM
   Name Server: NS2.US.DELL.COM
   Name Server: NS3.US.DELL.COM
   Name Server: NS4.US.DELL.COM
   Name Server: NS5.US.DELL.COM

 

So can you query one of those directly for that dell record?

 

C:\>dig @ns1.us.dell.com en.community.dell.com                   
                                                                 
; <<>> DiG 9.9.5-W1 <<>> @ns1.us.dell.com en.community.dell.com  
; (1 server found)                                               
;; global options: +cmd                                          
;; Got answer:                                                 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53220                
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 6     
;; WARNING: recursion requested but not available                        
                                                                         
;; OPT PSEUDOSECTION:                                                    
; EDNS: version: 0, flags:; udp: 4096                                    
;; QUESTION SECTION:                                                     
;en.community.dell.com.         IN      A                                
                                                                         
;; ANSWER SECTION:                                                       
en.community.dell.com.  600     IN      CNAME   commweb-ps3.us.dell.com.
commweb-ps3.us.dell.com. 600    IN      A       143.166.170.97           
                                                                         
;; AUTHORITY SECTION:                                                    
us.dell.com.            600     IN      NS      ns5.us.dell.com.         
us.dell.com.            600     IN      NS      ns4.us.dell.com.         
us.dell.com.            600     IN      NS      ns2.us.dell.com.         
us.dell.com.            600     IN      NS      ns1.us.dell.com.         
us.dell.com.            600     IN      NS      ns3.us.dell.com.         
                                                                         
;; ADDITIONAL SECTION:                                                   
ns1.us.dell.com.        600     IN      A       143.166.82.251           
ns2.us.dell.com.        600     IN      A       143.166.82.252           
ns3.us.dell.com.        600     IN      A       143.166.224.3            
ns4.us.dell.com.        600     IN      A       143.166.224.11           
ns5.us.dell.com.        600     IN      A       143.166.83.13            
                                                                         
;; Query time: 57 msec                                                   
;; SERVER: 143.166.82.251#53(143.166.82.251)                             
;; WHEN: Thu Feb 20 07:57:31 Central Standard Time 2014                  
;; MSG SIZE  rcvd: 265           

 

If you can not query the authoritative servers for that domain, its possible you have network connectivity issue to that netblock if your asking roots.  Or the dns servers your forwarding too have an issue, like I said you need to move up the chain of dns your using to find where the problem is.  If you directly ask where you forward and he can not look it up, but you can from directly from authoritative servers.. Then your forwarder has a problem - you should report it to them.  Or use a different one, or use multiple forwarders.                              
                                                                       

 

                                            
                                                                       

Link to comment
Share on other sites

Hello,

Say your dns server did not answer you in a timely fashion.  Set a timer to wait longer in dig, so does your AD query roots or forward?

C:\Users\user>dig en.community.dell.com +time=30

; <<>> DiG 9.9.5-W1 <<>> en.community.dell.com +time=30

;; global options: +cmd

;; connection timed out; no servers could be reached

Extended the time and still nothing.

About the AD, here is the DNS section:

post-25747-0-69477700-1392907542.png

A quick translation:

Visor de sucesos = Event log (there no errors from this year or last even)

Zonas de busqueda directa = Forward lookup Zones

Zonas de busqueda inserva = Reverse lookup Zones

Where should I look for this information you are asking me? :)

Why don't you try looking up something else?  Seems odd to me that it takes your dns 150ms to return the root servers?  But he answered atleast -- so your timeout lookup up the dell records just means he did not find it from who he asks and so why it timed out asking him.. Did you try it again in a second or so?  See if he got an answer by then?  If not you need to move up the chain to see why your having a problem?

Im gonna do a google.com

C:\Windows\system32>dig google.com

; <<>> DiG 9.9.5-W1 <<>> google.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58950

;; flags: qr aa; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1280

;; QUESTION SECTION:

;google.com. IN A

;; ANSWER SECTION:

google.com. 300 IN A 173.194.41.100

google.com. 300 IN A 173.194.41.102

google.com. 300 IN A 173.194.41.101

google.com. 300 IN A 173.194.41.103

google.com. 300 IN A 173.194.41.97

google.com. 300 IN A 173.194.41.98

google.com. 300 IN A 173.194.41.96

google.com. 300 IN A 173.194.41.110

google.com. 300 IN A 173.194.41.99

google.com. 300 IN A 173.194.41.104

google.com. 300 IN A 173.194.41.105

;; Query time: 110 msec

;; SERVER: 192.168.100.29#53(192.168.100.29)

;; WHEN: Thu Feb 20 15:50:47 Hora est?ndar romance 2014

;; MSG SIZE rcvd: 215

C:\Windows\system32>

 

so you can lookup who the authoritative dns is with a whois

user@linuxbox:~$ whois en.community.dell.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered

with many different competing registrars. Go to http://www.internic.net

for detailed information.

No match for "EN.COMMUNITY.DELL.COM".

>>> Last update of whois database: Thu, 20 Feb 2014 14:59:11 UTC <<<

NOTICE: The expiration date displayed in this record is the date the

registrar's sponsorship of the domain name registration in the registry is

currently set to expire. This date does not necessarily reflect the expiration

date of the domain name registrant's agreement with the sponsoring

registrar. Users may consult the sponsoring registrar's Whois database to

view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois

database through the use of electronic processes that are high-volume and

automated except as reasonably necessary to register domain names or

modify existing registrations; the Data in VeriSign Global Registry

Services' ("VeriSign") Whois database is provided by VeriSign for

information purposes only, and to assist persons in obtaining information

about or related to a domain name registration record. VeriSign does not

guarantee its accuracy. By submitting a Whois query, you agree to abide

by the following terms of use: You agree that you may use this Data only

for lawful purposes and that under no circumstances will you use this Data

to: (1) allow, enable, or otherwise support the transmission of mass

unsolicited, commercial advertising or solicitations via e-mail, telephone,

or facsimile; or (2) enable high volume, automated, electronic processes

that apply to VeriSign (or its computer systems). The compilation,

repackaging, dissemination or other use of this Data is expressly

prohibited without the prior written consent of VeriSign. You agree not to

use electronic processes that are automated and high-volume to access or

query the Whois database except as reasonably necessary to register

domain names or modify existing registrations. VeriSign reserves the right

to restrict your access to the Whois database in its sole discretion to ensure

operational stability. VeriSign may restrict or terminate your access to the

Whois database for failure to abide by these terms of use. VeriSign

reserves the right to modify these terms at any time.

The Registry database contains ONLY .COM, .NET, .EDU domains and

Registrars.

user@linuxbox:~$

 

Domain Name: DELL.COM

   Registrar: SAFENAMES LTD

   Name Server: NS1.US.DELL.COM

   Name Server: NS2.US.DELL.COM

   Name Server: NS3.US.DELL.COM

   Name Server: NS4.US.DELL.COM

   Name Server: NS5.US.DELL.COM

 

So can you query one of those directly for that dell record?

I pinged the first one ns1.us.dell.com and didn't reply or even resolve a IP...

 

C:\>dig @ns1.us.dell.com en.community.dell.com

Couldn't find anything either...

If you can not query the authoritative servers for that domain, its possible you have network connectivity issue to that netblock if your asking roots.  Or the dns servers your forwarding too have an issue, like I said you need to move up the chain of dns your using to find where the problem is.  If you directly ask where you forward and he can not look it up, but you can from directly from authoritative servers.. Then your forwarder has a problem - you should report it to them.  Or use a different one, or use multiple forwarders.

Well, tomorrow the people who we pay for internet access (not our ISP) comes to better a deal; They aren't in the technical area but I will talk to them about this issue and see what they say...
Link to comment
Share on other sites

If I had to guess I would say since all of the nameservers are listed as US nameservers in the name   Name Server: NS1.US.DELL.COM

 

That its possible you are blocked from access to them for your location.. If you can not ping them or resolve them it points to that sort of issue. Or nameserver your using has problem.  What I would suggest is in your forwarder section of your AD dns, you did not show that.  create a specific conditional forwarder for dell.com to ask a public dns that you can reach, say googledns or opendns or level 3 public 4.2.2.2

 

Do direct query to one of those - can your resolve the EN.COMMUNITY.DELL.COM that way..  If so there is your solution.

 

as to where you setup forwarders

 

http://technet.microsoft.com/en-us/library/cc754941.aspx

Configure a DNS Server to Use Forwarders

If you need more help in finding how to configure forwarders or conditional forwarders let me know and can fire up a VM and show you some screenshots. But you had previously stated that your AD forwards to your router - so I would have to assume you know how you did that, etc. Or looked to validate that it does in fact do that ;)

Can you query any of them by IP directly

Parent glue for dell.com found: ns1.us.dell.com (143.166.82.251)

Parent glue for dell.com found: ns2.us.dell.com (143.166.82.252)

Parent glue for dell.com found: ns3.us.dell.com (143.166.224.3)

Parent glue for dell.com found: ns4.us.dell.com (143.166.224.11)

Parent glue for dell.com found: ns5.us.dell.com (143.166.83.13)

Testing I did against their nameservers shows good.

example

Name server ns1.us.dell.com (143.166.82.251) answers queries over UDP.

Name server ns1.us.dell.com (143.166.82.251) answers queries over TCP.

Name server ns1.us.dell.com (143.166.82.251) is not recursive.

Name server ns1.us.dell.com (143.166.82.251) authoritative for dell.com.

This is the same for all of their listed NS --

Link to comment
Share on other sites

Hello,

If I had to guess I would say since all of the nameservers are listed as US nameservers in the name   Name Server: NS1.US.DELL.COM

 

That its possible you are blocked from access to them for your location..

Blocked from Dell? Doesn't it seem highly unlikely?

Wikipedia is also based in the US (the English page) and it isn't blocked...

If you can not ping them or resolve them it points to that sort of issue.  What I would suggest is in your forwarder section of your AD dns, you did not show that.  create a specific conditional forwarder for dell.com to ask a public dns that you can reach, say googledns or opendns or level 3 public 4.2.2.2

 

Do direct query to one of those - can your resolve the EN.COMMUNITY.DELL.COM that way..  If so there is your solution.

All that is that section is everything in the DNS section of AD. Where can I find this section you state a did not show?
Link to comment
Share on other sites

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

 

post-14624-0-55210100-1392915842.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!

Link to comment
Share on other sites

Hello,

But you had previously stated that your AD forwards to your router - so I would have to assume you know how you did that, etc. Or looked to validate that it does in fact do that ;)

I think Im assuming then; I assume since the gateway is my router, anything it doesn't find it automatically forwards it to the router.

Yes, thank you, let me see if your screenshots light up the path :)

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.