Re: Extend existing domain to a new DC build at a branch office


<snoconegod@xxxxxxxxx> wrote in message
news:1167926481.860372.245640@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hey fellas,

Thanks again for the stellar support! There's a ton to go through
here, so I'm going to do my best to address it all!

1. Ok, here's exactly what I've been putting into NSLookup and what
results:

from Chicago -> Toronto: DNS/PDC NT4 server name is "proxy", IP is
"192.168.1.1", domain is "INTERNET"
entry1: nslookup proxy 192.168.1.1
entry2: nslookup proxy.internet 192.168.1.1
entry3: nslookup proxy.internet.com 192.168.1.1

Only this last needs to be tested.

[Get in the habit of just using the full DNS name -- there
is seldom any benefit to testing the short name (just tests
how the local machine appends suffixes) and errors with
this just indicate a local machine issue anyway.]

output (same for each entry): "**** Can't find server name for address
192.168.1.1: Non-existent domain"
output (continued): "Server: UnKnown"
output (continued): "Address: 192.168.1.1"

All the stuff above is an irrelevant artifact of the way that NSLookup
works -- it checks for a reverse record for THE DNS server you
ask it to use and, even though you didn't tell it to do this, it reports
an error when that reverse record is not found.

output (continued): "UnKnown can't find proxy (or proxy.internet or
proxy.internet.com): Non-existent domain."

This is the part you care about. This means that either
the DNS server "192.168.1.1" does not "know" the answer
OR that it cannot be contacted correctly. (Can you prove
independendantly that it does know the answer for "proxy.internet.com"?
e.g., by looking in the 192.168.1.1 DNS server console and by
asking it directly, not from across the VPN?)


from Toronto -> Chicago: DNS/AD W2k3 server name is "scpdc", IP is
"10.10.10.1", domain is "2ndcity.local"
entry: nslookup scpdc.2ndcity.local 10.10.10.1
output: "**** Can't find server name for address 10.10.10.1:
Non-existent domain"
output (continued): "Server: UnKnown"
output (continued): "Address: 10.10.10.1"

Everything above is just NSLookup being obnoxiously 'helpful'.

output (continued): "Name: scpdc.2ndcity.local"
output (continued): "Address: 10.10.10.1"

And so it works in this direction.

Conclusion: Either your filters are ONE-WAY open for DNS
traffic (closed the other way) and/or your DNS server 192.168.1.1
doesn't know what you asked it....

I realized only after testing and re-reading your comments for the
upteenth time that I wasn't entering the full name of the Chicago DNS
server (I was just entering "scpdc" or "scpdc.2ndcity"), hence I was
getting bad results. Ugh! Not. Following. Instructions. Sorry!

You learned -- that is the important thing.

Now, correct me if I'm wrong, but does what I receved by doing the
lookup from Toronto -> Chicago prove that the Chicago DNS *is* working
properly?

YES. At least partially but it is working.

Even though it's not resolving the domain from the get-go,
it's traveling across the wire to query the 10.10.10.1 DNS server and
discovering that scpdc is, indeed, mapped to 10.10.10.1...right?

Right.

I also noticed a funky caveat on the Toronto servers. Note that I
don't have direct access to "proxy" (the DNS/PDC), but have been using
Term Services to access other member servers in Toronto to perform
these tests. Both of the other member servers appear to have the ISP's
DNS listed in their IP configuration settings (rather than
192.168.1.1).

This may not matter (much) NOW, but once you have your
own DNS server fully and properly configured (e.g., for the
AD domain to work) then you must NEVER set internal machine
to include an external DNS server (e.g., the ISP) which cannot
resolve ALL of the internal names -- it is a very common new
admin mistake to do this wrong, usually to try to mix internal and
external DNS on the DNS client NIC (don't do that, and realize
that even "servers" are almost always DNS clients too.)

For the NSLookup tests this doesn't matter because I have given
you the example of SPECIFYING which DNS server to use --
therefore any mistakes on the DNS "client" NIC are bypassed.

This is precisely why we use that final IP address parameter with
NSLookup to direct the query to a specific DNS server.

I imagined this was probably causing a few of the
problems, so I attempted to perform the exact same nslookup on proxy
from these member servers IN Toronto. I got the exact same error
messages. I'm worried that either it's 1) ISP DNS setting are mucking
things up (which it shouldn't be, since i used 192.168.1.1 in the
nslookup),

NOT IF you specify the internal DNS server as I indicated and
you reported above.

2) the DNS server on that NT4 box is just not set properly,
or

One of our possibilities. We can (almost completely) eliminate this
possibility by checking a local (to the DNS server) machine with
precisely the same query -- if that works then DNS is likely working,
and if it doesn't then DNS itself is likely the problem.

3) I'm not entering the domain name info properly in the nslookup.

Looks good from here:

nslookup FULL_NAME IP_OF_DNS_SERVER

(And you can check by cutting and pasting the same query from
the local machine to your Terminal Server session to guarantee
that re-typing is not causing a problem -- I am a big promoter of
cut n paste, not just because I am lazy, but because it eliminates
many inconsistancies.)

What exactly is the syntax for an NT4 domain, anyway? I seem to
remember it being nothing like the AD syntax of server.domain.com.

It is whatever you setup the zone as: If the zone on the NT4 DNS server
is "something.com" then it will be "ServerName.something.com" or
whatever. Again, by using the same command locally AND across the
VPN you can prove it either fails one place or in both.

Whew, ok, on to #2...

2. Yes, pinging the IP addresses from each location works just fine -
pinging names does not. I understand the ICMP traffic is running on a
different port than DNS.

Give us a general belief in Routing but doesn't prove the filters are
correct for DNS.

3. Telnet worked from both Chicago -> Toronto DNS and Toronto ->
Chicago DNS (got the blank screen, no timeout). To ensure I was doing
it properly, I also tried to hit port 53 on one of the app servers in
Toronto (from Chicago) and my own PC here in Chicago (from Toronto) and
both timed-out (since there's no DNS server running on either of
these).

Tends to indicate a DNS SERVER problem instead of a firewall
filter issue.

4. I'll give NETCAT a spin in a few minutes and report back with my
findings.

Ok (worth doing for the future -- to have NetCat) but checking the
NSLookup from the local side will pretty much confirm (or disprove)
the NT 4 DNS server isn't working right, or doesn't have this name
defined properly. (Also, just looking in the DNS console might be
useful.)

5. I had toyed with the idea of adding mappings to the hosts file on
the DNS servers on each side of the link. But that would just resolve
names only between those 2 computers, correct?

Right. It would have NOTHING to do with the "DNS SERVER" (i.e.,
the actual service) working and it would never help other clients who
ask this DNS server for help. It would be both a waste of time and
at best confusing. NSlookup bypasses such entries anyway, part of
the reason we use it -- we cannot trust most other programs to do
the DNS resolution, or to do it precisely against the DNS server WE
choose to use with NSlookup.

wouldn't cause all
computers on each side to magically begin resolving DNS names...?

Right. And it wouldn't fix anything here.

6. The Default-First-Site-Name was definitely in there. I went ahead
and renamed it Chicago, then created a Toronto site. However, there
were NO subnet rules in place.

There never are by default. All subnets that are unlisted (everything by
default) default to the Default-First-Site-Name, even if it is renamed).

You only need subnet entries when you start adding custom sites,
and then they become essential to thedefinition of the site(s).

I created one for each of the sites
(10.10.10.0/24 for Chicago, 192.168.1.0/24 for Toronto). And I'm
DEFINITELY planning on joining the PCs one-at-a-time and testing
everything first! :-)

After you get the (new) DC and one or two clients working you can
just do the rest in one big sweep.

7. NEW DEVELOPMENT: It appears that due to budget constraints, we're
going to purchase a new server for an application upgrade in Toronto,
then retask the old app server to be the DC/GC there. Unfortunately,
this server is running Win2k server, not Win2k3.

Not a giant problem. As long as you current domain is not in an
incompatible
"mode". Either "mixed mode" or "Win2000 Native mode" are both fine.
Otherwise you will need to upgrade it to Win2003.

Will that force me to
change any of my DCPromo steps? From what I've read, Win2k3 is much
easier to deploy...

I don't know if I agree or disagree with that -- but you should be
able to (whine, beg, etc) a Win2003 software upgrade for that old
server, right?

Win2003 is better, but for small domains the improvements are
mostly convenience and perhaps security improvements.

--
Herb Martin, MCSE MVP
www.LearnQuick.Com


.

Relevant Pages

  • Re: Some DNS server names will not resolve using internal servers
    ... I have done all the nslookup commands. ... All of our external ISP DNS ... Is there a trace i could do on the DNS server to tell me what is happening? ...
    (microsoft.public.windows.server.dns)
  • Re: Outlook 2003 wont verify Exchange account
    ... Interestingly enough..I ran nslookup on the machine and I did get an error. ... I found that my DNS server was configured a little strangely. ... If you open the 'Network Connections' folder then select the ... > The web has plenty of info for using this command as its not a Microsoft ...
    (microsoft.public.exchange.admin)
  • Re: W2K3 Enterprise R2 servers not accessible
    ... "Are you able to resolve their IP addresses using ... I have gone to a DOS prompt on my server in Domain B. I type nslookup and ... it now brings back the DNS server information. ...
    (microsoft.public.windows.server.dns)
  • Re: DNS Error 4015
    ... For DC SRVs registration. ... Review the output of the previous SRV query and determine if further action ... >> nslookup epc-domain.local ... >> Make sure the DC is using only the internal DNS server for the AD domain, ...
    (microsoft.public.windows.server.dns)
  • Re: DNS server removes his own record
    ... TTL and all those kinds of settings for the domain? ... FlagShip Integration Services ... Chicago, IL ... We have more than one DNS server. ...
    (microsoft.public.win2000.dns)
Loading