[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 309
  • Last Modified:

DNS and DC and internet hostname are the same, is that a problem?

Hi all,

My system has, for some obscure reason (don't ask!) the same name for its forest/dc as for an internet domain name that must be resolved externally. That said, my local DC and my remote hostname, that are located on the same server, have two (actually three) distinct A records, as shown below. Currently, I think it works correctly, but I'm afraid this is going to cause me trouble when I start setting up Apache (or any other webserver).

These are as it is configured locally:
A 10.0.0.10   MyDomain.com
A 10.123.456.789   MyDomain.com

This is the external configuration (at remote DNSs):
A 213.123.456.789  MyDomain.com

Note that the last three values are the same on the remote and the second local address. For some (logical) reason, the local auto-registration replaced 213 with 10 to fit it in the local subnet.

The question is, when I ping/trace mydomain.com, where do I go? Can I force it to go extern? But sometimes, or often, I need the domain name, not the internet host. Have I created a potential conflict, or is there a simple answer to all those questions?


Thanks in advance,
Abel
0
abel
Asked:
abel
  • 8
  • 6
1 Solution
 
AvonWyssCommented:
Hey abel... ;-)

If the following conditions are met, it will work as expected:
* The addresses in the local DNS are valid.
* The domain is not to be accessed from outside the LAN without a VPN connection (which would make the local addresses reachable)
* You don't need to access an service on the external server mydomain.com from within the LAN (but note that www.mydomain.com for instance is fine, given that the local DNS has the www address registered).

So, as for the ping/tracert etc., if the internet host is always referred to as www.mydomain.com, it will work, since there is no conflict with the LAN host.
0
 
abelAuthor Commented:
>  The addresses in the local DNS are valid.
Let's hope so. At least it appears to work correctly, even though my firewall is currently configured to block about everything that comes from the evil outside world.

When I use a workstation that is a workstation of the domain mydomain.com, and I use Ping to ServerName.MyDomain.com, I get the local address (10.0.0.10) and it replies. When I do the same to www.MyDomain.com, which is correctly registered at register.com (I don't trust myself enough to run the full dns configuration, as you might expect) it returns the address as it is registered, and the firewall blocks the ping as expected.

> The domain is not to be accessed from outside the LAN without a VPN connection
Domain, not host, I guess. www.mydomain.com should be accessible, as should otherCname.mydomain.com, with the exception for ServerName.mydomain.com and WorkstationNames.MyDomain.com. I do not intend to run terminal services or something like that from outside the local domain. I consider it too vulnerable (not terminal services, but passwords can be cracked and I am still very precautious since Nimda).

> You don't need to access an service on the external server mydomain.com from within the LAN
I don't really know what you mean with that. I guess not, though.

For the discussion at hand, does it matter that MyDomain.com has a wildcard registration: *.MyDomain.com?

Abel
0
 
AvonWyssCommented:
Ok. Let me elaborate a bit more:
There are two DNS server groups, each holding authoritive information about mydomain.com. One is your local DC. The other group consists of the servers at register.com. When a DNS server receives a request for a domain which it is authoritive for, it will answer the request without trying to cascade the request to other DOS servers.

This means:
* Anyone doing a request for mydomain.com on the net will get answers from the register.com DNS servers.
* Anyone doing a request for mydomain.com from within your LAN will get answers from the DNS service on your DC.

It is important to remember that the two DNS server groups do not communicate with each other. Now let's assume that the register.com DNS servers are working fine and return the wanted server. The tricky part is the DNS server on the LAN: what will happen if a client tries to connect to "www.mydomain.com"?

The LAN DNS will must the following entries set up:
* The entry "mydomain.com" must point to the DC itself. This concludes that you cannot use the name "mydomain.com" to surf or for other services (except mail which has separate DNS records) which you *could* do from outside the LAN. This was what I meant where you wrote that you didn't really know what I meant.
* Every machine has to be registered with its proper name.
* Every service you want to use from within the LAN must be registered (and have a name other than the machines). One of these will probably be "www.mydomain.com", which would have to be set up a A record to the same host where the public "www.mydomain.com" points to. Now, if you were using "test.mydoain.com" also, you would need to register this in your LAN DNS, etc.
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

 
abelAuthor Commented:
I see.
> * Every machine has to be registered with its proper name.
This means that I have to register every workstation name not only in the "Active Directory Users and Computers", but also in the DNS, with their appropriate computernames, the domain suffix and their respective ip-addresses, right? Like: WorkstationAbel.mydomain.com and WorkstationOtherGuy.mydomain.com.

From your last point, I understand that every A record (and C record?) must be registered twice: one time at register.com, and once locally. The latter I have not currently set up in that way. I assume that it works from your story about tcp/ip in the prev. thread: lower masks first. But that also means, that when my connection to the internet is lost, the local host will respond instead. And I guess from putting the public address in DNS, it will respond with "timeout" or "server unavailable" or something like that, which would be more appropriate. Am I correct?

Abel
0
 
AvonWyssCommented:
In the default setup, Windows will do both the AD and th DNS registrations automatically. DNS registrations of the wporkstations are by default even kept up-to-date by means of dynamic DNS registrations automatically (and that's what the /registerdns switch of ipconfig does: update the dynamic DNS records of that machine explicitly).

Last point: You only have top register the records which shall be available to the outside world at register.com - remember that the LAN computers will not do any query at register.com. This also means that if you have a machine  which has both a private and a public address, you can register the private address in the LAN DNS and therefore you will not get any connection errors from within your LAN even if the internet connection is lost. This is the suggested setup. You are correct that you would get a timeout/server unavailable message if you have a public IP that cannot be reached in your local DNS.

Note: the local DNS should be set up to use forwarders (you'll find these in the propterties of the LAN DNS server), so that it can resolve not only the names it is authoritive for, but also forward queries it cannot answer itself to other servers for processing. The forwarders should preferably be the DNS servers of your ISP, since they will most likely be the fastest and most reliable for you.
0
 
ritupatel112699Commented:
First  will checkits Primary DNS entry and try to resolved it first and you will reach that host which resolved by your prinary DNS result.
0
 
abelAuthor Commented:
AvonWyss,

From your last comment I understand that my current situation is mostly correctly configured. I think it correct to let the public domain lookups fail when I do not have a connection, even for my own domains. It at least reminds me that my connection is lost (though we have other tools for that).

But now I started to browse through the properties and, call me a newbie, which I am, but I am surprised at the presets that I find. Some are positive surprises (like: wow! can the computer do that?) and others I don't think I like, as with: MyLocalComputerName.myDomain.com is (also) assigned the external IP-address. That shouldn't be right, should it? I only want everything BUT the local computer names to be mapped to the external ip address.

Another thing I noticed that does not seem correct to me (but perhaps it is normal behaviour, I don't know) is that when I try to ping or tracert an illegal address, like someIllegalAddres.blabla, it always replies from my own assigned public ip address, and the route has only one stop, my computer. NsLookup says it finds someIllegalAddres.blabla.myDomain.com. Isn't that the primary domain suffix in action here? I rather have an answer like "Domain name not found".

I have set up the forwarding as you said, they point to the external dns servers.

Btw, I had this phenomena on a previous set up. Like when you browse and the browser can't find the correct ip-address, it resolves to the locally registered ip address. Now I understand that that is found in the DNS.

Abel
0
 
AvonWyssCommented:
Abel,

An IP address has no special treatment if it is a "private" address. In fact, the computer does not know (and cannot know) what addresses are private and what are public. That's why both the private and the public one of your AD server are registered in the DNS. It's quite a pain to disable this behaviour, but I'll be happy to provide you tith the MS KB nexeccary to do it if you like. Note, however, that this behaviour usually does not cause any problems since the public address can correctly be reached from inside the LAN, thus usually not causing any trouble.

When you try to ping a really invalid name, it should return a name resolution error and not ping at all. If you try to trace to an invalid IP address, you will at least see the default gateway as hop, and usually some hops more (until a gateway is reached which can identify the IP address as unreachable). However, when you enter the name of a computer (without the domain suffix), the DNS will also try to resolve the name with the suffix. This allows seamless mapping of local (unsuffixed) computer names to a real DNS domain name.
0
 
abelAuthor Commented:
> the DNS will also try to resolve the name with the suffix
I think then, that this happens to any name. For example, if I try to ping the name dns.register.com (which appeared to be invalid), I get this output:

Pinging dns.register.com.mydomain.com [216.81.51.111] with 32 bytes of data:

Request timed out.
... etc.

This also happens on the connected workstations (at least it is consistent).

If I ping a really invalid name, bla or bla.bla.bla.bla, or whatever name, I get the same results, like:

Pinging bla.bla.bla.bla.mydomain.com [216.81.51.111] with 32 bytes of data:

Request timed out.
... etc.


If I do it on the server, the request does not time out, but that is simply because of the settings of the firewall. It does this only when I have connection to the internet on both the workstation and the server.

If you say this is not normal, do you have any idea how to get rid of it?
0
 
abelAuthor Commented:
About the public/private domain names, I guess the easiest solution is to set up the webserver to simply not respond to requests that are of the form LocalServerName.MyDomainName.com. Or is the MSKB fix an easy one? You sound like this is default behaviour, do you recommend I just leave it like this?

I thought from the discussions on IP ranges and all that the ranges that are used for public ip addresses are completely distinct from the ones used for local ip addresses.
0
 
abelAuthor Commented:
About my last two comments, I assumed that "domain suffixes" (or suffices?) are the cause of that behaviour. I changed it to a simple "com" instead of the default local domain name, which appears to solve the problem to some extend. Unfortunately it seems to be impossible to remove the domain suffix completely. Why is that?

I think that the original question has been answered by now. Most other questions deserve their own thread, I assume. I'll leave this open for only a few more days and if no new comments appear, I will close and reward you (AvonWyss) the points.

Abel
0
 
AvonWyssCommented:
Ah, sorry abel, I completely forgot about this Q. Well, while I also think that the suffixes are causing it, the name resolution should not be successful for these fake names with the setup as I suggested it.

The local DNS server does not resolve *.yourdomain, so that this would return a name error. However, the external DNS *does* resolve that kind of names, so that the record is returned. However, the internal machines should never ever get any record from the outside DNS regarding your domain. And that's what is strange. Please verify that the internal machines will not make DNS requests to the external DNS server.
0
 
abelAuthor Commented:
> Please verify that the internal machines will not make DNS requests to the external DNS server.
I think that I should write that sentence in golden ink on all my computers! ;-)

But seriously, I think the problem I had is very close to be solved. The VPN connection I have on almost all computers uses DHCP and I thought it was necessary for them to use it to operate correctly. Now that I set the settings myself, I noticed that it works well without DHCP. I've set the DNS servers to nothing but my own server and at first sight it appears to work as it should (and the way I want it).

The only remaining problem is that is does not resolve the www.MyDomain.com, ftp.MyDomain.com etc., but it *does* resolve ServerName.MyDomain.com and OtherComputerName.MyDomain.com. I hoped the external lookup would also include external lookup of names like www.MyDomain.com, but it appears that it does not even try to look them up externally. I assume (and without rereading your comments, I think you even said so) that I indeed have to include these domains in my DNS configuration.

Well, I did so. And guess what, it works! And with NoneExisting.MyDomain.com finally gives "Unknown host.." as answer when I ping it!
0
 
abelAuthor Commented:
You know what it is with TCP/IP and the like? When you have a sound configuration, you can explain everything and the protocols seem crystal clear. But once you start on your own, from scratch, and your scratch is not a sound configuration, then suddenly all these protocols seem messy, muddy and misty all at the same time. Just give me some (new or old) programming language and I'll get along much easier!

Thanks for all the good explanations!

Cheers!
Abel

0
 
AvonWyssCommented:
Able, I'm glad I was able to shed some light into the darkness of TCP/IP. Actually, I'm doing this stuff quite some time now and I still sometimes just don't fully understand what is happening (like, why the heck is the data not routed to where I have my static route to? etc.).
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 8
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now