Can see from one domain but not the other way around.

Do the records exist in DNS?  If they do, then the rules of I.T says it has to resolve.

If the machines at "grape" specify a DNS server that they can see which holds the correct records, then it will work.

Can you browse to the DNS server in question at the troubled site?

I would first check the DNS configuration for the machines in the Grape network in the DHCP scope options for Grape.

When you find out exactly what DNS servers client machine are getting in Grape then you can start looking at a few things.

1. If it's a DNS server in Grape, can you do nslookus and get Name resolution
2. if it's a DNS server in Orange, is port 53 allowed via the site-to-site VPN link for user's in Grape to communicate with their DNS server (i'm assuming that is not the case otherwise you would have other issues ^^)

Also another thing to fix is the DNS Suffixes that is handed out to the machines. Can you ping FQDN from Grape ? If yes, then you would need to add a DNS suffix in the search list to be able to get this all to work.

let us know !

Coast-IT

The DNS servers are the same in that Grape DNS has a secondary zone fully populated with Orange and Orange DNS has a fully populated secondary zone for Grape. Both Forward and Reverse zones.

Are these two separate Windows Forests? Have you set up forest trusts correctly?

termitenshort,

The clients at the sites get their local DNS servers from DHCP. When an nslookup is performed at Grape for devices at Orange i get "Non-existent domain" error.

dbsq13,

They are two separate companies that merged so I'm assuming they are different forests. I have a fully active trust in place for both ways and they test active. Is there some other setting I should look at? And if this is the case why does it work one way and not the other?

Have you tried to ping using the FQDN? (server.domain.com)

If that works you need to add the DNS suffix of the other domain to your LAN connection ( this can be done by GPO http://blogs.techrepublic.com.com/datacenter/?p=2665 )
 

advanced-ip-settings.JPG

Not it, see the results of FQDN ping.
Capture.JPG

check your DNS IP's 98.7 of all problems.

I've set conditional forwards for this kind of thing in the past and it works fairly well.  Or, adding the domain suffix to the workstations for the domain I'm having trouble resolving.

jcw20, all DNS info looks correct.

digitap, conditional and standard stub/secondary zones are setup correctly.

Any other ideas? Networking issues, anything else?

If ping is working, then the network is configured properly.  If you can perform an nslookup and DNS resolves name to ip or ip to name for remote hosts, then DNS is working.  If you can't ping a remote host by host name, then the workstation you are on isn't able to resolve to the remote domain.  It's not clear if you've tried this, but what happens when you try to ping a remote host by FQDN?

You are troubleshooting the wrong thing:

Netbios resolution is the one that populates the browselist. Netbios is bound to a single broadcast domain. So, why is Grape able to ping by netbios name to Orange, you ask??? it's because of a cached record called a netbios cache or a WINS cache...

netbios has very much the same structure as DNS. So, instead of using HOST to configure a site to site connection between the two domain master browsers, you can configure the LMHOST file to include the two PDCe's...

Netbios is not routeable, but with the help of WINS you can route netbios traffic. Instead of WINS you can use an LMHOST lookup..

IN ADDITION TO, if youa re able to ping other pcs by IP address, you should also be able to ping by FQDN. So, DNS is not resolving between domains, and that needs to be addressed as well. My guess is, you don't have reference of both domain within the forward lookup zones of DNS.

Are you behind a nat firewall if you need to forward nebios and dns ports?

Hello !

You say that you get a non-existant domain when doing nslookup, this means that the domain must be different in grape and Orange, this also mean that the DNS Servers in Grape would need to have DNS forwarders setup for the specific domain of Orange to the DNS Servers hosting that zone.

For example, if the domains are grape.biz and orange.biz, in the grape.biz DNS Server you'd need to setup a forwarder to orange.biz DNS pointing to that specific DNS Server in the Orange network.

Also you need to ensure that there is connectivity between the 2 DNS servers. I.E Firewall port 53 open for grape.bz DNS server to talk to the Orange.bix DNS server via the VPN tunnel.

Anyways that's my guess at this point.

Let us know what next step you took!

Termite

Also I just read that you have the forwarders setup as well as the secondary zones setup.

The important question is from grape, are you able to resolve fully qualified name from the Orange site ?

If so, this means that you simply need to add the orange dns suffix in the DNS search list, if you look at the screenshot from minvis, it's at the bottom of that screenshot where you need to add that zone.

I originally mentioned that piece but it wasn't as clear :)

Termite

DNS is a routeable protocol. There is a problem with the DNS SRV records that DCdiag will tell you:

Author, please provide the output of this information:

DCdiag /test:DNS

(on the domain controller)

Once you fix DNS you still will not be able to ping by computername, nor will you be able to see a list of computers from the remote site in my network places.

Furthermore, the netlogon service requires netbios resolution...

@ ChiefIT, that is not true, you are always able to ping by computer name with the correct setup in DNS.

The proof is that currently from the Orange network is able to do so, there is indeed something missing in the DNS config on the Grape side which prevents KCCOIT to ping Grape -> Orange using computer name only.

In our organization, we have about 400 sites with many different domains and we can ping any computer by its name only. It's all a matter of getting DNS resolution to flow all accross with fully qualified name and then adding the right DNS suffixes in the list.

Wow, so many post updates how to begin. First, thank you all for replying, they are all great suggestions. However, I have tried each and every one of them in the past with no success. As my original post explains, the settings for both sides are exactly the same. Every piece of the puzzle is the same from the routers to the servers and the dns settings.

DIGITAP: From the 'broken' side I can ping by IP but not by FQDN. DNS has the correct info in it.

CHIEFIT: WINS is turned on and fully populated on both sides.

JCW20: There is a setting within the Sonciwall s2s vpn that forwards requests across the NAT. Both sides have this setting enabled.

TERMITENSHORT: Yes, the suffix information is correctly added and the fqdn still does not work.

I think I've reached the point where I need to open a paid help request to Microsoft and to Sonicwall to find out what is going on.

If wins is fully operationional and populated, then these computers are being blocked from netbios coming into the computers. This means a system state firewall, like windows firewall. System State, is defined as a firewall that blocks incomine messages UNLESS the communications are originated by the computer.

So, let's say DNS is blocked by the firewall. If that computer goes out and does a DNS query, it will except a response. If it doesn't the packet will be dropped...

It does sound like you took the extra steps needed to route Netbios traffic from one site to the other. Now it sounds like a little blockage...

DIGITAP, yes that is setup.  You can see why I'm so lost. I've done everything that my 14 years have taught me and yet things still do not work. ARGH! Major fail on my part.

can you do a port query to determine of the SMB and Netbios ports needed to traffic this data across a WAN connection is blocked?

The syntax is:

Portquery -n (IP address) -o port 137 -p both

port 137 TCP is the port that is consistant for both SMB and Netbios file shares between sites. ONE THING YOU MIGHT CONSIDER IS many ISPs block this port for IT security reasons.

So sonic wall I believe has the ability to use PAT to change the port and change back at the distant end..

in other words:

Site A with port 137>>sonic wall PAT to an alternative listening port>>>>>>Internet cloud>>>>>Sonic wall changes the listening port back to port 137>>>Site B

You might make two phone calls. One is for IT support to Sonic and ask them how to get SMB shares between sites that block port 137 TCP. The other is to ask your ISP if they block port 137 TCP.

Hey there,

I was looking at everything we've asked you to do so far and it's quite a lot of stuff ^^. I have another test that I'd like you to do to check on something.

From a PC in Grape,
1 - run nslookup
2 - Type server and the ip of a DNS server in Orange
3 - try and resolve a server name in Orange using just its name and / or the FDQN to see what happen.

I'm starting to think more and more at a networking issue between the sites that is not allowing DNS to work properly..

let us know.

Termite ^^

Other ports for SMB sharing and Netbios sharing:

Netbios method:
port 137 WINS and Netbios TCP and UDP
port 138 Netbios datagram port UDP
port 139 Netbios datagram port UDP

SMB shares:
port 137 WINS and netbios TCP
port 445 SMB shares using netbios datagarams UDP and TCP

port query can check all at once:

portqry  -o (IP address) -n 137,138, 139, 445 -p both

@termitenshort:

nslookup is stricly an ICMP message used for DNS troubleshooting. The browselist and doman master browser services are populated by two ways simultaneously. One is through netbios and the other is through Server Message Block (SMB) shares. NBLOOKUP will allow you to troubleshoot netbios translation.

Though, I agree that there might be a few DNS discrepancies on this network, I believe the original intent of this was to populate the browselist of both sites, to file and print share. The best way to troubleshooot DNS discrepancies is to run DCdiag /test:DNS. That will show you the DNS discrepancies of the network, (if any exist).

@KCCOIT :: Don't beat yourself up over it.  These things happen...lot's of smart people on this question, so we'll get it squared away I'm sure.

Have you gone through the tests presented by ChiefIT?  IF those queries are being blocked, then performing the tests he's prescribed should weed that out.  Ultimately, if it is being blocked then it'll be a firewall rule.  Check out your LAN > VPN and VPN > LAN on both sonicwall appliances.

@ChiefIT:

I agree this is strictly for troubleshooting and should give us a good reason why DNS does not work. Mapping a drive does not require netbios and can done via DNS only. Same goes for IP printing

Ultimately the goal seems to be tp print and see mapped drive when people are @ grape but comming from the Orange site which should require DNS resolution only.

I also agree with you that browsing the network neighbourhood does require netbios to function properly like you metinoned

If there any firewalls involved  you need open the dns port on them and, correct any ip address errors.

I will post the findings from the latest suggestions. I'm traveling to a our new office all this coming week to install s2s for them. If/When I have downtime I'll perform these test.

UNC stands for Universal Naming Convention for a reason. A path can be mapped by IP address, fully qualified domain name, or Computername. Depending upon how you map, also depends upon what routed protocol you use..

For an IP based UNC Path   //xxx.xxx.xxx.xxx/share  You are using ARP that transaltes IP to MAC address.

For a fully qualified Domain name //servername.domain.name/share you are using DNS, that translates to an IP and then uses ARP to translate to a MAC address.

For a computername UNC map //servername/share  you are using Netbios, (NO MATTER HOW YOU LOOK AT IT DNS WILL NOT PERFORM NETBIOS RESOLUTION).

Netbios is a BROADCAST form of communications. When a client logs on it will send out a netbios broadcast. That broadcast is used to set up a browselist in "MY NETWORK PLACES". it is not used for many other reasons.

PING is a multiple communication protocol diagnostic utility. It can check DNS, Netbios and ARP. All you have to do is use it the right way.

Ping xxx.xxx.xxx.xxx
ping servername.domain.name    ((or reverse)) Ping -a xxx.xxx.xxx.xxx   are DNS and reverse DNS lookups

ping servername   (is a netbios ping)

It is my opinion, you can NOT ping or map by Netbios  (which is the most common protocol used for all Common Information File Shares  (CIFS shares),  or also referred to as Server Message Block Shares (SMB shares).

If you go to the command prompt of any computer and type:

Net config redir

you will see that SMB shares uses a NETBIOS BINDING, (not dns).

When you permit DNS to perform Netbios lookup, which is an option in DNS, you are actually telling the DNS server that it can query a netbios server. That netbios server is the site master browser, or domain master browser, NOT the DNS server itself to strip off the Domain name for just a computer name. This is a waste of computer resources, because what I am about to tell you will shock you. In order for DNS to perform Netbios resolution, you need a Netbios name server..

DNS transfers zones between other servers,

WINS replication does the same for netbios resolution.

To get Site-to-Site Netbios resolution, you need WINS, OR an LMHOST connection between the site master browsers. DNS will not work for netbios resolution...

USE PING:

Ping FQDN
Ping NETBIOS NAME
PING IP ADDRESS

That will tell you what you can and can't map with your current configuraiton.

Now, PIng can be decieving.

Many network administrators, prevent:

ICMP echo.

This is a ping request. and is often filtered by the router to drop Pings into your LANS.

Many software firewalls do the same. (this includes Windows firewall). So ping by IP first.

Actually, what you need to do is turn ip helper OFF between the sites.

Glad turning it off worked and thanks for the points!