Cannot ping DNS from outside 2

[Timhi]

Hi all. I have a little annoying problem with not being able to ping my domain name.

I am migrating from a 2000 network to 2003. I am replacing the PDC and DNS. My goal is to set up a new domain (with a different name) and keep the old one up with trusts until everything is migrated.

Since I've never done this before I setup a test box. I set up a PDC with Active Directory and DNS with a test domain name. Physically it is connected to my network. DNS is up. and I can join to the test domain from a workstation, but I can't ping the domain itself (lets call test.org)

I can ping the IP of the PDC from anywhere in the building, and I can also ping pdc.test.org, but pinging test.org doesn't reslve to anything. I figure it is some record that I am missing in my DNS zone file. Anyone have any idea what I am missing here? It's been a few days so everything should be propegated.

Thanks.

 

[Dublin73]

in a lAN based setup (which you have) you typically wouldn't expect to be able to ping a domain name, as opposed to a particular host. For example host.domain.com

Over the internet you can ping a domain name. For example tek-tips.com. What's the logic behind trying to ping your domain name?

 

[Davetoo]

Actually, your DC should respond to a domain ping internally.

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

 

[Davetoo]

Setup a forwarder in your DNS pointing to the old DNS server.

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

 

[58sniper]

Let's verify a couple of things first.

1. You have a machine that's a member of the "new" domain.
2. You have that machine configured to use the DNS from the DC on the "new" domain.
3. You're attempting to ping your domain, "domain.com" from that workstation, and you're not getting name resolution.

Correct?

If that's the case, that has nothing to do with forwarders needed (although you do need to configure them eventually to look at your ISPs DNS servers)

Next, just curious as to why you're creating a new domain, and not just adding the new DC to the existing domain....

Pat Richard
Microsoft Exchange MVP
Contributing author The Complete Reference: Microsoft Exchange Server 2007

 

[Timhi]

Hey guys, thanks for your help on this. The reason I am creating a new domain instead of adding a DC to my existing domain is because the company is getting rebranded and it needs to be ranamed. I have no intention of upgrading the current (ancient) DC to 2003 so that rules out a simple rename. I am creating a new forest instead of a new tree because the restructure is involving a new DNS, new DHCP, and more creative subnetting so I thought it best to just start fresh. It's only one domain so no big deal.

58sniper, that's all correct. The name resolution issue has been resolved after adding a zone to my existing domain and is working now. So the two domains can see each other. However, it still can't be contacted from the internet. When I do a lookup from dnsstuff.com it turns up nothing. I need the domain to be contactable from the outside because it will be the primary DNS server for our company and needs to be able to handle queries from the internet because we use VPN and host a web server.

My other side-problem currently is that I am setting up an external trust between the root dc on the new domain (2003) and the root dc on the current domain (2000) and it is not working. I can ping from DC-to-DC between forests, but when I try to establish the trust it says "the Domain Controller in testdomain.org cannot be contacted" and vice versa. Any ideas?

Thanks!

 

[Davetoo]

Did you purchase your domainname.com and setup the DNS with your ISP to point to your servers?

I'm hoping you've setup a DMZ, firewalls, etc. to protect your network as well?

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

 

[Timhi]

I'm using a test domain name so I didn't register it. It's on the internal network so the firewall is in place on the gateway.

So the ISP is responsible for configuring forwarders to the new domain? I'm just making sure there isn't some magic button I forgot to press.

Any ideas on what I'm doing wrong with my trust? I'm just making two one-way external trusts on each server to point to each other but it says they can't contact each other despite being able to ping each other (by domain name and host name).

 

[pgaliardo]

If the domain name is not registered and you didn't notify your ISP, it won't be seen from the outside. Your ISP will need to set up the PTR and A records so that it will replicate on DNS servers through-out the Internet. Your internal DNS is only for internal name resolution. You set up forwarders on your internal DNS to point to your ISP's DNS servers for name resolution of domains outside your organiation.

 

[Davetoo]

pgaliardo is correct.

I'm Certifiable, not cert-ified.
It just means my answers are from experience, not a book.

 

[Timhi]

Ok, thanks. that makes an awful amount of sense.

I read that trusts use netbios for resolution. So I guess that's why they couldn't talk. I guess that means I need a WINS server.

 

[Timhi]

I installed WINS server in the test domain (current domain already has it). I set up replication partners on both servers, but when I try to replicate it says gives the following:

event 4102 "The connection was aborted by the remote WINS. Remote WINS may not be configured to replicate with the server."

and event 5721 "The session setup to the Windows NT or Windows 2000 Domain Controller \\*host*.*domain*.org for the domain *domain* failed because the Domain Controller did not have an account *test*.org. needed to set up the session by this computer *testhost*.

ADDITIONAL DATA
If this computer is a member of or a Domain Controller in the specified domain, the aforementioned account is a computer account for this computer in the specified domain. Otherwise, the account is an interdomain trust account with the specified domain.

So it ties back to the same reason the trust wasn't working. Do I need to set up a special computer or user account in AD? I checked for disjointed DNS suffix's but that is not the problem. Any ideas?

Thanks.

 

[Dublin73]

regarding your trust relationship problem, this could be due to any number of things. A few things to try...

Map a drive to the C drive of the other domain's Domain Controller. Or go through Start> Run>. either way type in the UNC path. For example, \\domaincontroller\c$

You will likely be prompted to enter the username and password for the other domain when trying to make the connection, enter your domain admin credentials (for the domain you're connecting to). Once connected, attempt to set up the trust relationship again.

Next thing to check are the local security settings on your domain controllers. You may need to change these temporarily (I stress temporarily) from their defaults to make the trust relationship connection. Try setting these as follows and see how you get on with it.

RestrictAnonymous and RestrictAnonymousSam:

Network access: Allow anonymous SID/Name translation ENABLED

Network access: Do not allow anonymous enumeration of SAM accounts

DISABLED

Network access: Do not allow anonymous enumeration of SAM accounts and

shares DISABLED

Network access: Let Everyone permissions apply to anonymous users

ENABLED

Network access: Named pipes can be accessed anonymously ENABLED

Network access: Restrict anonymous access to Named Pipes and shares

DISABLED

LM Compatibility:

Network security: LAN Manager authentication level "LM & NTLM

responses" or "Send LM & NTLM - use NTLMV2 session security if negotiated"

SMB Signing, SMB Encrypting, or both:

Microsoft network client: Digitally sign communications (always)

DISABLED

Microsoft network client: Digitally sign communications (if server

agrees) ENABLED

Microsoft network server: Digitally sign communications (always)

DISABLED

Microsoft network server: Digitally sign communications (if client

agrees) ENABLED

Domain member: Digitally encrypt or sign secure channel data (always)

DISABLED

Domain member: Digitally encrypt secure channel data (when it is

possible) ENABLED

Domain member: Digitally sign secure channel data (when it is

possible) ENABLED

Domain member: Require strong (Windows 2000 or later) session key

DISABLED

 

[Timhi]

I'll try that and let you know. Thanks for the info, Dublin.