Forwarding DNS Resolution Requests
Peoples, I currently run a Windows 2000 AD Domain. The primary server runs DNS so that everyone can resolve members of that domain (shock horror!). For the purpose of this example, lets call the domain billybob.
Peoples,
I currently run a Windows 2000 AD Domain. The primary server runs DNS so that everyone can resolve members of that domain (shock horror!).
For the purpose of this example, lets call the domain "billybob.com".
Now, the company i work for was bought out by a far larger company, and our WAN's have now been connected... but i wish to forward any resolutions for THEIR domains to THEIR servers.
So -
billybob.com would get resolved locally
"Far Larger Company.com" would get resolved on their Servers.
Is there any way i can configure DNS on the server to Forward any requests for their domain to their server ?
I currently run a Windows 2000 AD Domain. The primary server runs DNS so that everyone can resolve members of that domain (shock horror!).
For the purpose of this example, lets call the domain "billybob.com".
Now, the company i work for was bought out by a far larger company, and our WAN's have now been connected... but i wish to forward any resolutions for THEIR domains to THEIR servers.
So -
billybob.com would get resolved locally
"Far Larger Company.com" would get resolved on their Servers.
Is there any way i can configure DNS on the server to Forward any requests for their domain to their server ?
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
Originally posted by Alec§taar:
Quote:THIS MAY SOUND DUMB, IF I UNDERSTOOD YOU CORRECTLY BUT, here goes:
Couldn't you just set them up with their OWN DNS server instead of pointing them to YOUR dns server?
Well, the problem is that they have their huge network, and i have my resonable sized network (25 C Class's)... both where completely seperate and still are, there is no trust delgations or anything...
So i want to resolve anything in their domain, but without adding it all to my domain...
Im thinking the only way this is going to happen is to get them to export their list and then i can try to import it ?
However, it would be much easier... if i could point all resolution for *.bigcompany.com to IPADDRESS...
That make more sense ?
Quote:THIS MAY SOUND DUMB, IF I UNDERSTOOD YOU CORRECTLY BUT, here goes:
Couldn't you just set them up with their OWN DNS server instead of pointing them to YOUR dns server?
Well, the problem is that they have their huge network, and i have my resonable sized network (25 C Class's)... both where completely seperate and still are, there is no trust delgations or anything...
So i want to resolve anything in their domain, but without adding it all to my domain...
Im thinking the only way this is going to happen is to get them to export their list and then i can try to import it ?
However, it would be much easier... if i could point all resolution for *.bigcompany.com to IPADDRESS...
That make more sense ?
Have you looked into using a stub zone? The definition given in help would not indicate that you can use it for this but giving it a try on my lab it seems that it would.
Create a stub zone for "Far Larger Company.com" and then do a transfer from master. This should import all the name servers and I believe any A records for PC's that identify themselves as servers.
Essentially, you'll still point to your local DNS server and it will now have a list of name servers for "Far Larger Company.com" zone.
Let me know how this works out for you as I'm a bit curious. Never really had to implement a stub zone before.
Create a stub zone for "Far Larger Company.com" and then do a transfer from master. This should import all the name servers and I believe any A records for PC's that identify themselves as servers.
Essentially, you'll still point to your local DNS server and it will now have a list of name servers for "Far Larger Company.com" zone.
Let me know how this works out for you as I'm a bit curious. Never really had to implement a stub zone before.
Some info. I'm not sure how adding DNS forwarders to "Far Larger Company.com" will affect existing DNS resolutions from your ISP, so be weary.
FYI, in Windows Server 2003 you can create a conditional approach to DNS resolution so it will forward requests to the most appropriate DNS server based on the originating domain. Although I don't think this functionality is available in Windows 2000 it's something to think about never the less.
Otherwise, zen69x's suggestion should do the trick in the mean time.
FYI, in Windows Server 2003 you can create a conditional approach to DNS resolution so it will forward requests to the most appropriate DNS server based on the originating domain. Although I don't think this functionality is available in Windows 2000 it's something to think about never the less.
Otherwise, zen69x's suggestion should do the trick in the mean time.
Posted by Alec§taar
Quote:P.S.=> Curious also - CAN YOU USE LMHOSTS WITH "Active Directory" still for name resolutions? Thanks for Info... apk
LMHOSTS is more of a replacement for WINS and also has the ability to identify various attibutes.
AD is dependent on DNS and most importantly the service records contained there. The HOSTS file would seem to be more directly related, however I don't know if there is any capability to point somehow to a service record via the HOSTS file.
To be honest, I've never tried to use anything other than DNS for AD. As for straight name resolution, I'd be more apt myself to use the HOSTS file as I've not messed with a LMHOSTS file in many years.
Quote:P.S.=> Curious also - CAN YOU USE LMHOSTS WITH "Active Directory" still for name resolutions? Thanks for Info... apk
LMHOSTS is more of a replacement for WINS and also has the ability to identify various attibutes.
AD is dependent on DNS and most importantly the service records contained there. The HOSTS file would seem to be more directly related, however I don't know if there is any capability to point somehow to a service record via the HOSTS file.
To be honest, I've never tried to use anything other than DNS for AD. As for straight name resolution, I'd be more apt myself to use the HOSTS file as I've not messed with a LMHOSTS file in many years.
Don't know how I missed this one, but...
Set your default forwarder for your ISP, and conditional forwarder(s) for the other domain(s) you need direct resolution. This is what we do in the lab (10 forests with about 25 domains) and it works fine. Stub zones require a connection with one DNS box (setup replication), and the stub zone then looks for other name servers in that domain to query and work with. A conditional forwarder, on the other hand, requires no such configuration and simply forwards all request to those DNS servers on the behalf of the clients (although default behavior would be recursive, where the DNS server tries to resolve it itself).
Set your default forwarder for your ISP, and conditional forwarder(s) for the other domain(s) you need direct resolution. This is what we do in the lab (10 forests with about 25 domains) and it works fine. Stub zones require a connection with one DNS box (setup replication), and the stub zone then looks for other name servers in that domain to query and work with. A conditional forwarder, on the other hand, requires no such configuration and simply forwards all request to those DNS servers on the behalf of the clients (although default behavior would be recursive, where the DNS server tries to resolve it itself).
LMHOSTS is only useful for NetBIOS name resolution. If you have resources on your network that require it, and WINS isn't an option, then it will work. Even in that case, it is only useful for:
1. Crossing subnets/broadcast boundries
2. Speeding name resolution in the case of slow network response (too much broadcast traffic already)
3. "Spoofing" the desired name of a resource and pointing it to an existing machine (like "intranet" and having the IP point to your internal website or registering machines as specific resources, such as domain controllers)
AD requires DNS, and more importantly the SRV record support. However, Windows clients and servers will try to failover to NTLM and NetBIOS (versus Kerberos and DNS) to resolve and access resources. This is why a horribly broken AD environment can appear to be working, but in fact have many issues that "occur" intermittently.
While Windows 2000 and the first AD required DNS, Exchange Server 2000 still required NetBIOS for resolving Exchange servers. Clients also needed NetBIOS with Outlook XP and prior to connect to those servers. Exchange Server 2003 fixes *most* of this when combined with Outlook 2003, but might still need NetBIOS for console usage. Again, it just depends on the resources in your network.
1. Crossing subnets/broadcast boundries
2. Speeding name resolution in the case of slow network response (too much broadcast traffic already)
3. "Spoofing" the desired name of a resource and pointing it to an existing machine (like "intranet" and having the IP point to your internal website or registering machines as specific resources, such as domain controllers)
AD requires DNS, and more importantly the SRV record support. However, Windows clients and servers will try to failover to NTLM and NetBIOS (versus Kerberos and DNS) to resolve and access resources. This is why a horribly broken AD environment can appear to be working, but in fact have many issues that "occur" intermittently.
While Windows 2000 and the first AD required DNS, Exchange Server 2000 still required NetBIOS for resolving Exchange servers. Clients also needed NetBIOS with Outlook XP and prior to connect to those servers. Exchange Server 2003 fixes *most* of this when combined with Outlook 2003, but might still need NetBIOS for console usage. Again, it just depends on the resources in your network.
