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
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
ASKER
> 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.
> 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
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.
> 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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.c
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
> * 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.c
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
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.
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.
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.
ASKER
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.myDoma
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.m
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
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.myDoma
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.m
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
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.
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.
ASKER
> 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.
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.c
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?
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.
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.c
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?
ASKER
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.MyDomainNa
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.
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.
ASKER
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
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
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.
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.
ASKER
> 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
Well, I did so. And guess what, it works! And with NoneExisting.MyDomain.com finally gives "Unknown host.." as answer when I ping it!
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
Well, I did so. And guess what, it works! And with NoneExisting.MyDomain.com finally gives "Unknown host.." as answer when I ping it!
ASKER
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
Thanks for all the good explanations!
Cheers!
Abel
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.).
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.