Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Planning internal DNS Namespace
- Thread starter 25degc
- Start date
- Thread starter
- #3
Thank you AlexIT. Is there any chance you can expand on these name resolution/browsing issues, or can you point me to somewhere where I can find out more information.
It seems to me that this is one of the most critical decisions in the design of AD, but there is so little information about it!
It seems to me that this is one of the most critical decisions in the design of AD, but there is so little information about it!
isguyatlanta
MIS
if you use company.com for your web space and company.com for your internal space, you will have to pull some wool over your DNS servers unless you feel like putting your AD DNS server out on the internet. Then you will have records available on the internet for machines that are not reachable from the internet.
I have 4 DNS server 2 external and 2 internal (because some @$$ used company.com for out internal name) Now I have to manually match some records on both sets of servers for accessing our internet site from inside. Also, I cannot outsource my DNS because of certain revese lookup records that have to exist on the external servers that are in the 10 address space, ISPs will not put those record on thier servers.
Use company.local or something other than what can be registered.
I have 4 DNS server 2 external and 2 internal (because some @$$ used company.com for out internal name) Now I have to manually match some records on both sets of servers for accessing our internet site from inside. Also, I cannot outsource my DNS because of certain revese lookup records that have to exist on the external servers that are in the 10 address space, ISPs will not put those record on thier servers.
Use company.local or something other than what can be registered.
A little more info on the DNS...
The naming structure is: sub-child.child.parent.god
This is why mail comes from mailserver.yourdomain.com, and why the client computers are going to be workstation.yourdomain.com. That .com at the end tells that its a corporate network. "yourdomain" is that name you wound up registering when the one you really wanted was taken by someone else. If you have a server named "local" then this will AUTOMATICALLY be local.yourdomain.com if it belongs to "yourdomain.com" So if you put the "local" anywhere BUT at the end, you are in effect creating a sub-domain that someone COULD try to reach (I know there is a local.net, so if you were to use yourdomain.local.net you would be a child of someone else's domain. I had this happen on my test network a year ago, where my server accidentally wound up a child of another domain. I had the strangest DNS records appearing...replicating from the "parent" domain, and when I wanted to add my own records they took forever to resolve...I was populating another domains DNS servers! Big security issues there!)
Your clients will end being workstation1.yourdomain.com they will not correctly resolve You will have to add records to your internal DNS server telling the clients the private IP address 192.168.1.XXX while the external DNS knows this web site by the public IP 90.1.1.XXX. Your clients can wind up trying to use two different name records at different times, which makes for strange client problems that would only occur depending upon the cached DNS records. Diagnosing these cache records errors can require tremendous effort.
Now, if you put .local at the END, you have created a entire new structure that cannot be associated through any external connection (because there is no nameserver for ".local" like there is or ".com, .bis, .name, etc.) Actually you don't need to use .local at all, ANYTHING except a valid register will be fine (i.e. DNSserver.mydomain.franklindelanoreroosevelt), M$ has decided that .local is what they will automatically attach if you choose that selection box...
Alex
The naming structure is: sub-child.child.parent.god
This is why mail comes from mailserver.yourdomain.com, and why the client computers are going to be workstation.yourdomain.com. That .com at the end tells that its a corporate network. "yourdomain" is that name you wound up registering when the one you really wanted was taken by someone else. If you have a server named "local" then this will AUTOMATICALLY be local.yourdomain.com if it belongs to "yourdomain.com" So if you put the "local" anywhere BUT at the end, you are in effect creating a sub-domain that someone COULD try to reach (I know there is a local.net, so if you were to use yourdomain.local.net you would be a child of someone else's domain. I had this happen on my test network a year ago, where my server accidentally wound up a child of another domain. I had the strangest DNS records appearing...replicating from the "parent" domain, and when I wanted to add my own records they took forever to resolve...I was populating another domains DNS servers! Big security issues there!)
Your clients will end being workstation1.yourdomain.com they will not correctly resolve You will have to add records to your internal DNS server telling the clients the private IP address 192.168.1.XXX while the external DNS knows this web site by the public IP 90.1.1.XXX. Your clients can wind up trying to use two different name records at different times, which makes for strange client problems that would only occur depending upon the cached DNS records. Diagnosing these cache records errors can require tremendous effort.
Now, if you put .local at the END, you have created a entire new structure that cannot be associated through any external connection (because there is no nameserver for ".local" like there is or ".com, .bis, .name, etc.) Actually you don't need to use .local at all, ANYTHING except a valid register will be fine (i.e. DNSserver.mydomain.franklindelanoreroosevelt), M$ has decided that .local is what they will automatically attach if you choose that selection box...
Alex
- Status
Similar threads
- Locked
- Question