How to configure the DNS in AD to return local addresses for some names in a domain and use the external DNS...












0















I am relatively new to Active Directory.



In the LAN, we need to return some local addresses for some names but for some other names, we just want to get the IP as-is from the external DNS.



Example: IN LAN:
name1.domain.com : 192.168.1.114 (this would be resolved by AD and points to a LAN server)
name2.domain.com : 52.45.123.21 (this would be resolved by a public DNS)



OUTSIDE THE LAN:
name1.domain.com : 34.54.12.56 (this would be resolved by a public DNS)
name2.domain.com : 52.45.123.21 (this would be resolved by a public DNS)



How can we do that without replicating all the DNS entries from the public server in the Active Directory DNS ?



What I see now is that to get the IN-LAN examples to work, I need to define BOTH name1 AND name2 (even though I dont want to modify the IP of name2 -- the public DNS value is what I want).



In other words, I wish to redefine some of the DNS entries but not others.



Any way to do that ?



Thanks










share|improve this question













migrated from superuser.com Jan 23 at 14:10


This question came from our site for computer enthusiasts and power users.














  • 1





    Which Windows Server version are you using? Are you talking about a domain that's hosted by an AD DC (using Microsoft DNS Server service), or about a domain that's hosted elsewhere but only resolved through an AD DC?

    – grawity
    Jan 21 at 14:05






  • 1





    You're looking for split brain DNS and/or pin-point internal zone

    – Seth
    Jan 21 at 14:52
















0















I am relatively new to Active Directory.



In the LAN, we need to return some local addresses for some names but for some other names, we just want to get the IP as-is from the external DNS.



Example: IN LAN:
name1.domain.com : 192.168.1.114 (this would be resolved by AD and points to a LAN server)
name2.domain.com : 52.45.123.21 (this would be resolved by a public DNS)



OUTSIDE THE LAN:
name1.domain.com : 34.54.12.56 (this would be resolved by a public DNS)
name2.domain.com : 52.45.123.21 (this would be resolved by a public DNS)



How can we do that without replicating all the DNS entries from the public server in the Active Directory DNS ?



What I see now is that to get the IN-LAN examples to work, I need to define BOTH name1 AND name2 (even though I dont want to modify the IP of name2 -- the public DNS value is what I want).



In other words, I wish to redefine some of the DNS entries but not others.



Any way to do that ?



Thanks










share|improve this question













migrated from superuser.com Jan 23 at 14:10


This question came from our site for computer enthusiasts and power users.














  • 1





    Which Windows Server version are you using? Are you talking about a domain that's hosted by an AD DC (using Microsoft DNS Server service), or about a domain that's hosted elsewhere but only resolved through an AD DC?

    – grawity
    Jan 21 at 14:05






  • 1





    You're looking for split brain DNS and/or pin-point internal zone

    – Seth
    Jan 21 at 14:52














0












0








0








I am relatively new to Active Directory.



In the LAN, we need to return some local addresses for some names but for some other names, we just want to get the IP as-is from the external DNS.



Example: IN LAN:
name1.domain.com : 192.168.1.114 (this would be resolved by AD and points to a LAN server)
name2.domain.com : 52.45.123.21 (this would be resolved by a public DNS)



OUTSIDE THE LAN:
name1.domain.com : 34.54.12.56 (this would be resolved by a public DNS)
name2.domain.com : 52.45.123.21 (this would be resolved by a public DNS)



How can we do that without replicating all the DNS entries from the public server in the Active Directory DNS ?



What I see now is that to get the IN-LAN examples to work, I need to define BOTH name1 AND name2 (even though I dont want to modify the IP of name2 -- the public DNS value is what I want).



In other words, I wish to redefine some of the DNS entries but not others.



Any way to do that ?



Thanks










share|improve this question














I am relatively new to Active Directory.



In the LAN, we need to return some local addresses for some names but for some other names, we just want to get the IP as-is from the external DNS.



Example: IN LAN:
name1.domain.com : 192.168.1.114 (this would be resolved by AD and points to a LAN server)
name2.domain.com : 52.45.123.21 (this would be resolved by a public DNS)



OUTSIDE THE LAN:
name1.domain.com : 34.54.12.56 (this would be resolved by a public DNS)
name2.domain.com : 52.45.123.21 (this would be resolved by a public DNS)



How can we do that without replicating all the DNS entries from the public server in the Active Directory DNS ?



What I see now is that to get the IN-LAN examples to work, I need to define BOTH name1 AND name2 (even though I dont want to modify the IP of name2 -- the public DNS value is what I want).



In other words, I wish to redefine some of the DNS entries but not others.



Any way to do that ?



Thanks







windows domain-name-system active-directory






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jan 21 at 13:33









GilbertGilbert

31




31




migrated from superuser.com Jan 23 at 14:10


This question came from our site for computer enthusiasts and power users.









migrated from superuser.com Jan 23 at 14:10


This question came from our site for computer enthusiasts and power users.










  • 1





    Which Windows Server version are you using? Are you talking about a domain that's hosted by an AD DC (using Microsoft DNS Server service), or about a domain that's hosted elsewhere but only resolved through an AD DC?

    – grawity
    Jan 21 at 14:05






  • 1





    You're looking for split brain DNS and/or pin-point internal zone

    – Seth
    Jan 21 at 14:52














  • 1





    Which Windows Server version are you using? Are you talking about a domain that's hosted by an AD DC (using Microsoft DNS Server service), or about a domain that's hosted elsewhere but only resolved through an AD DC?

    – grawity
    Jan 21 at 14:05






  • 1





    You're looking for split brain DNS and/or pin-point internal zone

    – Seth
    Jan 21 at 14:52








1




1





Which Windows Server version are you using? Are you talking about a domain that's hosted by an AD DC (using Microsoft DNS Server service), or about a domain that's hosted elsewhere but only resolved through an AD DC?

– grawity
Jan 21 at 14:05





Which Windows Server version are you using? Are you talking about a domain that's hosted by an AD DC (using Microsoft DNS Server service), or about a domain that's hosted elsewhere but only resolved through an AD DC?

– grawity
Jan 21 at 14:05




1




1





You're looking for split brain DNS and/or pin-point internal zone

– Seth
Jan 21 at 14:52





You're looking for split brain DNS and/or pin-point internal zone

– Seth
Jan 21 at 14:52










1 Answer
1






active

oldest

votes


















1














Unfortunately, manual setup is the name of the game for this scenario. As @Seth pointed out in his comments, you're talking about what we call a Split-Brain DNS setup. And while there are several methods to accomplish this, depending on your exact network layout and the software running your various services, they all come down to "manual upkeep."



The Domain Name System is designed with the idea that each zone has only one record of authority. That is, if your zone is domain.com then every record that ends in domain.com is defined the same. It may be replicated among multiple name servers, but that is for redundancy reasons not for "different values in different places" reasons. Which in turn means that name1.domain.com, by the DNS design, should return the same value everywhere.



You can "hijack" this by exerting overriding control within a network that you fully control.



One common method is Split-Brain DNS. If you have a private internal DNS server on your network, then you can load it up with local zones that don't match the publicly available information (one brain on the internet, the other on the LAN). Now your local server will answer with information from its zone configuration, assuming that it is the primary authority for up-to-date info; and likewise the public DNS will believe it is in charge. Neither will look to the other for information because they believe they are the primary source. But that is the kicker, each one thinks it is in charge, so there is no reason for it to look elsewhere. And that results in you having to maintain two separate zone configurations (not always fun, but a part of the average day for most of us). If either server realized it needed to look elsewhere it would be admitting it wasn't authortative for the zone, and that it needs to look elsewhere for every request made of it.



Another method that you'll still see fairly often is the DNS Rewrite (aka DNS Doctoring). This method is only effective if the domain.com name isn't your AD domain (read: nothing internally needs to be able to automatically update DNS entries on this domain using the built-in Windows DNS client). In the event that you have an existing external domain.com setup for services other than AD-DS, but you want internal users to hit a different IP (an internal portal version, a faster route, whatever) then you can do re-writing. In this setup the one and only DNS server is the internet/public DNS, and you have elements at your network edge that modify DNS responses. This used to be a common setup on lots of NAT devices when making static maps (like when setting up DMZ elements). The NAT sees a DNS response coming through with the response value of 34.54.12.56 and it automatically replaces the data in the payload so that the response received by the client is 192.168.1.114. In this scenario, you maintain the full DNS zone in the external server; and then you keep your rewrite rules up-to-date with only the things you need to have be "different" within your network. Again, there is manual upkeep here as well, but this method has the advantage that you only double-enter the specific items that need doctoring, not every single record (and the down side is that you have to open/inspect/modify packets flowing through the network at the LAN edge).



Either way requires manual intervention and double-entry of data. The more common and stable approach is the Split-Brain method. But, as DNS Doctoring shows, there are other ways to accomplish what you're aiming for; each with their own benefits and drawbacks.



TLDR If you want the standard approach that is most commonly used, and that we know works through plenty of experience, then you should stick with Split-Brain DNS. It works with AD, even on the primary AD/DS domain. But it does require having a fully authoritative zone in both the internal and external worlds.






share|improve this answer
























  • Thank you so much for your long and detailed explanation. In some sense, we already have implemented a split brain setup where we need to duplicate ALL entries of the domain in order to replace only a few. It is annoying to setup and will also be a maintenance issue in the future I am sure... but it works. The DNS Doctoring approach seems to be what we want. The domain for which we need to rewrite IPs is not the AD domain. Roughly, how do we setup dns doctoring / rewrite in AD ? I searched the AD DNS help and could not find anything on that.

    – Gilbert
    Jan 25 at 0:24











  • DNS rewriting isn't done by AD, it's anathema to "proper" DNS and I doubt MS will even mention it. You'd have to do that with an inspection device on your network edge. It got prevalence as part of the NAT mappings for hidden DMZ segments, so you'll find it in lots of routers for NATed addresses. But straight rewriting outside of that will require a packet inspector watching your traffic, selecting DNS, looking into it, and selectively changing values; this is a very invasive procedure. Do-able, but mostly not kosher in modern networks that aren't super heavy handed on lack of privacy.

    – Ruscal
    Jan 25 at 0:33













  • Thanks again. In this case, we will stick with our split brain setup. Before AD, our DNS was pfsense and it was doing the DNS forwarding exactly as we want now (i.e. use the names that are locally defined and rely on the authoritative DNS server for the other names).

    – Gilbert
    Jan 25 at 15:07











  • Makes sense. pfsense is a packet inspector on the network edge. If you already have enough pfsense appliances, you could use them for rewriting again (sounds like you've set that up before). Then have your AD-DNS servers set with a conditional forwarder to look at them for the target domain.

    – Ruscal
    Jan 25 at 20:46











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f950389%2fhow-to-configure-the-dns-in-ad-to-return-local-addresses-for-some-names-in-a-dom%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














Unfortunately, manual setup is the name of the game for this scenario. As @Seth pointed out in his comments, you're talking about what we call a Split-Brain DNS setup. And while there are several methods to accomplish this, depending on your exact network layout and the software running your various services, they all come down to "manual upkeep."



The Domain Name System is designed with the idea that each zone has only one record of authority. That is, if your zone is domain.com then every record that ends in domain.com is defined the same. It may be replicated among multiple name servers, but that is for redundancy reasons not for "different values in different places" reasons. Which in turn means that name1.domain.com, by the DNS design, should return the same value everywhere.



You can "hijack" this by exerting overriding control within a network that you fully control.



One common method is Split-Brain DNS. If you have a private internal DNS server on your network, then you can load it up with local zones that don't match the publicly available information (one brain on the internet, the other on the LAN). Now your local server will answer with information from its zone configuration, assuming that it is the primary authority for up-to-date info; and likewise the public DNS will believe it is in charge. Neither will look to the other for information because they believe they are the primary source. But that is the kicker, each one thinks it is in charge, so there is no reason for it to look elsewhere. And that results in you having to maintain two separate zone configurations (not always fun, but a part of the average day for most of us). If either server realized it needed to look elsewhere it would be admitting it wasn't authortative for the zone, and that it needs to look elsewhere for every request made of it.



Another method that you'll still see fairly often is the DNS Rewrite (aka DNS Doctoring). This method is only effective if the domain.com name isn't your AD domain (read: nothing internally needs to be able to automatically update DNS entries on this domain using the built-in Windows DNS client). In the event that you have an existing external domain.com setup for services other than AD-DS, but you want internal users to hit a different IP (an internal portal version, a faster route, whatever) then you can do re-writing. In this setup the one and only DNS server is the internet/public DNS, and you have elements at your network edge that modify DNS responses. This used to be a common setup on lots of NAT devices when making static maps (like when setting up DMZ elements). The NAT sees a DNS response coming through with the response value of 34.54.12.56 and it automatically replaces the data in the payload so that the response received by the client is 192.168.1.114. In this scenario, you maintain the full DNS zone in the external server; and then you keep your rewrite rules up-to-date with only the things you need to have be "different" within your network. Again, there is manual upkeep here as well, but this method has the advantage that you only double-enter the specific items that need doctoring, not every single record (and the down side is that you have to open/inspect/modify packets flowing through the network at the LAN edge).



Either way requires manual intervention and double-entry of data. The more common and stable approach is the Split-Brain method. But, as DNS Doctoring shows, there are other ways to accomplish what you're aiming for; each with their own benefits and drawbacks.



TLDR If you want the standard approach that is most commonly used, and that we know works through plenty of experience, then you should stick with Split-Brain DNS. It works with AD, even on the primary AD/DS domain. But it does require having a fully authoritative zone in both the internal and external worlds.






share|improve this answer
























  • Thank you so much for your long and detailed explanation. In some sense, we already have implemented a split brain setup where we need to duplicate ALL entries of the domain in order to replace only a few. It is annoying to setup and will also be a maintenance issue in the future I am sure... but it works. The DNS Doctoring approach seems to be what we want. The domain for which we need to rewrite IPs is not the AD domain. Roughly, how do we setup dns doctoring / rewrite in AD ? I searched the AD DNS help and could not find anything on that.

    – Gilbert
    Jan 25 at 0:24











  • DNS rewriting isn't done by AD, it's anathema to "proper" DNS and I doubt MS will even mention it. You'd have to do that with an inspection device on your network edge. It got prevalence as part of the NAT mappings for hidden DMZ segments, so you'll find it in lots of routers for NATed addresses. But straight rewriting outside of that will require a packet inspector watching your traffic, selecting DNS, looking into it, and selectively changing values; this is a very invasive procedure. Do-able, but mostly not kosher in modern networks that aren't super heavy handed on lack of privacy.

    – Ruscal
    Jan 25 at 0:33













  • Thanks again. In this case, we will stick with our split brain setup. Before AD, our DNS was pfsense and it was doing the DNS forwarding exactly as we want now (i.e. use the names that are locally defined and rely on the authoritative DNS server for the other names).

    – Gilbert
    Jan 25 at 15:07











  • Makes sense. pfsense is a packet inspector on the network edge. If you already have enough pfsense appliances, you could use them for rewriting again (sounds like you've set that up before). Then have your AD-DNS servers set with a conditional forwarder to look at them for the target domain.

    – Ruscal
    Jan 25 at 20:46
















1














Unfortunately, manual setup is the name of the game for this scenario. As @Seth pointed out in his comments, you're talking about what we call a Split-Brain DNS setup. And while there are several methods to accomplish this, depending on your exact network layout and the software running your various services, they all come down to "manual upkeep."



The Domain Name System is designed with the idea that each zone has only one record of authority. That is, if your zone is domain.com then every record that ends in domain.com is defined the same. It may be replicated among multiple name servers, but that is for redundancy reasons not for "different values in different places" reasons. Which in turn means that name1.domain.com, by the DNS design, should return the same value everywhere.



You can "hijack" this by exerting overriding control within a network that you fully control.



One common method is Split-Brain DNS. If you have a private internal DNS server on your network, then you can load it up with local zones that don't match the publicly available information (one brain on the internet, the other on the LAN). Now your local server will answer with information from its zone configuration, assuming that it is the primary authority for up-to-date info; and likewise the public DNS will believe it is in charge. Neither will look to the other for information because they believe they are the primary source. But that is the kicker, each one thinks it is in charge, so there is no reason for it to look elsewhere. And that results in you having to maintain two separate zone configurations (not always fun, but a part of the average day for most of us). If either server realized it needed to look elsewhere it would be admitting it wasn't authortative for the zone, and that it needs to look elsewhere for every request made of it.



Another method that you'll still see fairly often is the DNS Rewrite (aka DNS Doctoring). This method is only effective if the domain.com name isn't your AD domain (read: nothing internally needs to be able to automatically update DNS entries on this domain using the built-in Windows DNS client). In the event that you have an existing external domain.com setup for services other than AD-DS, but you want internal users to hit a different IP (an internal portal version, a faster route, whatever) then you can do re-writing. In this setup the one and only DNS server is the internet/public DNS, and you have elements at your network edge that modify DNS responses. This used to be a common setup on lots of NAT devices when making static maps (like when setting up DMZ elements). The NAT sees a DNS response coming through with the response value of 34.54.12.56 and it automatically replaces the data in the payload so that the response received by the client is 192.168.1.114. In this scenario, you maintain the full DNS zone in the external server; and then you keep your rewrite rules up-to-date with only the things you need to have be "different" within your network. Again, there is manual upkeep here as well, but this method has the advantage that you only double-enter the specific items that need doctoring, not every single record (and the down side is that you have to open/inspect/modify packets flowing through the network at the LAN edge).



Either way requires manual intervention and double-entry of data. The more common and stable approach is the Split-Brain method. But, as DNS Doctoring shows, there are other ways to accomplish what you're aiming for; each with their own benefits and drawbacks.



TLDR If you want the standard approach that is most commonly used, and that we know works through plenty of experience, then you should stick with Split-Brain DNS. It works with AD, even on the primary AD/DS domain. But it does require having a fully authoritative zone in both the internal and external worlds.






share|improve this answer
























  • Thank you so much for your long and detailed explanation. In some sense, we already have implemented a split brain setup where we need to duplicate ALL entries of the domain in order to replace only a few. It is annoying to setup and will also be a maintenance issue in the future I am sure... but it works. The DNS Doctoring approach seems to be what we want. The domain for which we need to rewrite IPs is not the AD domain. Roughly, how do we setup dns doctoring / rewrite in AD ? I searched the AD DNS help and could not find anything on that.

    – Gilbert
    Jan 25 at 0:24











  • DNS rewriting isn't done by AD, it's anathema to "proper" DNS and I doubt MS will even mention it. You'd have to do that with an inspection device on your network edge. It got prevalence as part of the NAT mappings for hidden DMZ segments, so you'll find it in lots of routers for NATed addresses. But straight rewriting outside of that will require a packet inspector watching your traffic, selecting DNS, looking into it, and selectively changing values; this is a very invasive procedure. Do-able, but mostly not kosher in modern networks that aren't super heavy handed on lack of privacy.

    – Ruscal
    Jan 25 at 0:33













  • Thanks again. In this case, we will stick with our split brain setup. Before AD, our DNS was pfsense and it was doing the DNS forwarding exactly as we want now (i.e. use the names that are locally defined and rely on the authoritative DNS server for the other names).

    – Gilbert
    Jan 25 at 15:07











  • Makes sense. pfsense is a packet inspector on the network edge. If you already have enough pfsense appliances, you could use them for rewriting again (sounds like you've set that up before). Then have your AD-DNS servers set with a conditional forwarder to look at them for the target domain.

    – Ruscal
    Jan 25 at 20:46














1












1








1







Unfortunately, manual setup is the name of the game for this scenario. As @Seth pointed out in his comments, you're talking about what we call a Split-Brain DNS setup. And while there are several methods to accomplish this, depending on your exact network layout and the software running your various services, they all come down to "manual upkeep."



The Domain Name System is designed with the idea that each zone has only one record of authority. That is, if your zone is domain.com then every record that ends in domain.com is defined the same. It may be replicated among multiple name servers, but that is for redundancy reasons not for "different values in different places" reasons. Which in turn means that name1.domain.com, by the DNS design, should return the same value everywhere.



You can "hijack" this by exerting overriding control within a network that you fully control.



One common method is Split-Brain DNS. If you have a private internal DNS server on your network, then you can load it up with local zones that don't match the publicly available information (one brain on the internet, the other on the LAN). Now your local server will answer with information from its zone configuration, assuming that it is the primary authority for up-to-date info; and likewise the public DNS will believe it is in charge. Neither will look to the other for information because they believe they are the primary source. But that is the kicker, each one thinks it is in charge, so there is no reason for it to look elsewhere. And that results in you having to maintain two separate zone configurations (not always fun, but a part of the average day for most of us). If either server realized it needed to look elsewhere it would be admitting it wasn't authortative for the zone, and that it needs to look elsewhere for every request made of it.



Another method that you'll still see fairly often is the DNS Rewrite (aka DNS Doctoring). This method is only effective if the domain.com name isn't your AD domain (read: nothing internally needs to be able to automatically update DNS entries on this domain using the built-in Windows DNS client). In the event that you have an existing external domain.com setup for services other than AD-DS, but you want internal users to hit a different IP (an internal portal version, a faster route, whatever) then you can do re-writing. In this setup the one and only DNS server is the internet/public DNS, and you have elements at your network edge that modify DNS responses. This used to be a common setup on lots of NAT devices when making static maps (like when setting up DMZ elements). The NAT sees a DNS response coming through with the response value of 34.54.12.56 and it automatically replaces the data in the payload so that the response received by the client is 192.168.1.114. In this scenario, you maintain the full DNS zone in the external server; and then you keep your rewrite rules up-to-date with only the things you need to have be "different" within your network. Again, there is manual upkeep here as well, but this method has the advantage that you only double-enter the specific items that need doctoring, not every single record (and the down side is that you have to open/inspect/modify packets flowing through the network at the LAN edge).



Either way requires manual intervention and double-entry of data. The more common and stable approach is the Split-Brain method. But, as DNS Doctoring shows, there are other ways to accomplish what you're aiming for; each with their own benefits and drawbacks.



TLDR If you want the standard approach that is most commonly used, and that we know works through plenty of experience, then you should stick with Split-Brain DNS. It works with AD, even on the primary AD/DS domain. But it does require having a fully authoritative zone in both the internal and external worlds.






share|improve this answer













Unfortunately, manual setup is the name of the game for this scenario. As @Seth pointed out in his comments, you're talking about what we call a Split-Brain DNS setup. And while there are several methods to accomplish this, depending on your exact network layout and the software running your various services, they all come down to "manual upkeep."



The Domain Name System is designed with the idea that each zone has only one record of authority. That is, if your zone is domain.com then every record that ends in domain.com is defined the same. It may be replicated among multiple name servers, but that is for redundancy reasons not for "different values in different places" reasons. Which in turn means that name1.domain.com, by the DNS design, should return the same value everywhere.



You can "hijack" this by exerting overriding control within a network that you fully control.



One common method is Split-Brain DNS. If you have a private internal DNS server on your network, then you can load it up with local zones that don't match the publicly available information (one brain on the internet, the other on the LAN). Now your local server will answer with information from its zone configuration, assuming that it is the primary authority for up-to-date info; and likewise the public DNS will believe it is in charge. Neither will look to the other for information because they believe they are the primary source. But that is the kicker, each one thinks it is in charge, so there is no reason for it to look elsewhere. And that results in you having to maintain two separate zone configurations (not always fun, but a part of the average day for most of us). If either server realized it needed to look elsewhere it would be admitting it wasn't authortative for the zone, and that it needs to look elsewhere for every request made of it.



Another method that you'll still see fairly often is the DNS Rewrite (aka DNS Doctoring). This method is only effective if the domain.com name isn't your AD domain (read: nothing internally needs to be able to automatically update DNS entries on this domain using the built-in Windows DNS client). In the event that you have an existing external domain.com setup for services other than AD-DS, but you want internal users to hit a different IP (an internal portal version, a faster route, whatever) then you can do re-writing. In this setup the one and only DNS server is the internet/public DNS, and you have elements at your network edge that modify DNS responses. This used to be a common setup on lots of NAT devices when making static maps (like when setting up DMZ elements). The NAT sees a DNS response coming through with the response value of 34.54.12.56 and it automatically replaces the data in the payload so that the response received by the client is 192.168.1.114. In this scenario, you maintain the full DNS zone in the external server; and then you keep your rewrite rules up-to-date with only the things you need to have be "different" within your network. Again, there is manual upkeep here as well, but this method has the advantage that you only double-enter the specific items that need doctoring, not every single record (and the down side is that you have to open/inspect/modify packets flowing through the network at the LAN edge).



Either way requires manual intervention and double-entry of data. The more common and stable approach is the Split-Brain method. But, as DNS Doctoring shows, there are other ways to accomplish what you're aiming for; each with their own benefits and drawbacks.



TLDR If you want the standard approach that is most commonly used, and that we know works through plenty of experience, then you should stick with Split-Brain DNS. It works with AD, even on the primary AD/DS domain. But it does require having a fully authoritative zone in both the internal and external worlds.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jan 23 at 14:50









RuscalRuscal

55829




55829













  • Thank you so much for your long and detailed explanation. In some sense, we already have implemented a split brain setup where we need to duplicate ALL entries of the domain in order to replace only a few. It is annoying to setup and will also be a maintenance issue in the future I am sure... but it works. The DNS Doctoring approach seems to be what we want. The domain for which we need to rewrite IPs is not the AD domain. Roughly, how do we setup dns doctoring / rewrite in AD ? I searched the AD DNS help and could not find anything on that.

    – Gilbert
    Jan 25 at 0:24











  • DNS rewriting isn't done by AD, it's anathema to "proper" DNS and I doubt MS will even mention it. You'd have to do that with an inspection device on your network edge. It got prevalence as part of the NAT mappings for hidden DMZ segments, so you'll find it in lots of routers for NATed addresses. But straight rewriting outside of that will require a packet inspector watching your traffic, selecting DNS, looking into it, and selectively changing values; this is a very invasive procedure. Do-able, but mostly not kosher in modern networks that aren't super heavy handed on lack of privacy.

    – Ruscal
    Jan 25 at 0:33













  • Thanks again. In this case, we will stick with our split brain setup. Before AD, our DNS was pfsense and it was doing the DNS forwarding exactly as we want now (i.e. use the names that are locally defined and rely on the authoritative DNS server for the other names).

    – Gilbert
    Jan 25 at 15:07











  • Makes sense. pfsense is a packet inspector on the network edge. If you already have enough pfsense appliances, you could use them for rewriting again (sounds like you've set that up before). Then have your AD-DNS servers set with a conditional forwarder to look at them for the target domain.

    – Ruscal
    Jan 25 at 20:46



















  • Thank you so much for your long and detailed explanation. In some sense, we already have implemented a split brain setup where we need to duplicate ALL entries of the domain in order to replace only a few. It is annoying to setup and will also be a maintenance issue in the future I am sure... but it works. The DNS Doctoring approach seems to be what we want. The domain for which we need to rewrite IPs is not the AD domain. Roughly, how do we setup dns doctoring / rewrite in AD ? I searched the AD DNS help and could not find anything on that.

    – Gilbert
    Jan 25 at 0:24











  • DNS rewriting isn't done by AD, it's anathema to "proper" DNS and I doubt MS will even mention it. You'd have to do that with an inspection device on your network edge. It got prevalence as part of the NAT mappings for hidden DMZ segments, so you'll find it in lots of routers for NATed addresses. But straight rewriting outside of that will require a packet inspector watching your traffic, selecting DNS, looking into it, and selectively changing values; this is a very invasive procedure. Do-able, but mostly not kosher in modern networks that aren't super heavy handed on lack of privacy.

    – Ruscal
    Jan 25 at 0:33













  • Thanks again. In this case, we will stick with our split brain setup. Before AD, our DNS was pfsense and it was doing the DNS forwarding exactly as we want now (i.e. use the names that are locally defined and rely on the authoritative DNS server for the other names).

    – Gilbert
    Jan 25 at 15:07











  • Makes sense. pfsense is a packet inspector on the network edge. If you already have enough pfsense appliances, you could use them for rewriting again (sounds like you've set that up before). Then have your AD-DNS servers set with a conditional forwarder to look at them for the target domain.

    – Ruscal
    Jan 25 at 20:46

















Thank you so much for your long and detailed explanation. In some sense, we already have implemented a split brain setup where we need to duplicate ALL entries of the domain in order to replace only a few. It is annoying to setup and will also be a maintenance issue in the future I am sure... but it works. The DNS Doctoring approach seems to be what we want. The domain for which we need to rewrite IPs is not the AD domain. Roughly, how do we setup dns doctoring / rewrite in AD ? I searched the AD DNS help and could not find anything on that.

– Gilbert
Jan 25 at 0:24





Thank you so much for your long and detailed explanation. In some sense, we already have implemented a split brain setup where we need to duplicate ALL entries of the domain in order to replace only a few. It is annoying to setup and will also be a maintenance issue in the future I am sure... but it works. The DNS Doctoring approach seems to be what we want. The domain for which we need to rewrite IPs is not the AD domain. Roughly, how do we setup dns doctoring / rewrite in AD ? I searched the AD DNS help and could not find anything on that.

– Gilbert
Jan 25 at 0:24













DNS rewriting isn't done by AD, it's anathema to "proper" DNS and I doubt MS will even mention it. You'd have to do that with an inspection device on your network edge. It got prevalence as part of the NAT mappings for hidden DMZ segments, so you'll find it in lots of routers for NATed addresses. But straight rewriting outside of that will require a packet inspector watching your traffic, selecting DNS, looking into it, and selectively changing values; this is a very invasive procedure. Do-able, but mostly not kosher in modern networks that aren't super heavy handed on lack of privacy.

– Ruscal
Jan 25 at 0:33







DNS rewriting isn't done by AD, it's anathema to "proper" DNS and I doubt MS will even mention it. You'd have to do that with an inspection device on your network edge. It got prevalence as part of the NAT mappings for hidden DMZ segments, so you'll find it in lots of routers for NATed addresses. But straight rewriting outside of that will require a packet inspector watching your traffic, selecting DNS, looking into it, and selectively changing values; this is a very invasive procedure. Do-able, but mostly not kosher in modern networks that aren't super heavy handed on lack of privacy.

– Ruscal
Jan 25 at 0:33















Thanks again. In this case, we will stick with our split brain setup. Before AD, our DNS was pfsense and it was doing the DNS forwarding exactly as we want now (i.e. use the names that are locally defined and rely on the authoritative DNS server for the other names).

– Gilbert
Jan 25 at 15:07





Thanks again. In this case, we will stick with our split brain setup. Before AD, our DNS was pfsense and it was doing the DNS forwarding exactly as we want now (i.e. use the names that are locally defined and rely on the authoritative DNS server for the other names).

– Gilbert
Jan 25 at 15:07













Makes sense. pfsense is a packet inspector on the network edge. If you already have enough pfsense appliances, you could use them for rewriting again (sounds like you've set that up before). Then have your AD-DNS servers set with a conditional forwarder to look at them for the target domain.

– Ruscal
Jan 25 at 20:46





Makes sense. pfsense is a packet inspector on the network edge. If you already have enough pfsense appliances, you could use them for rewriting again (sounds like you've set that up before). Then have your AD-DNS servers set with a conditional forwarder to look at them for the target domain.

– Ruscal
Jan 25 at 20:46


















draft saved

draft discarded




















































Thanks for contributing an answer to Server Fault!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f950389%2fhow-to-configure-the-dns-in-ad-to-return-local-addresses-for-some-names-in-a-dom%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Сан-Квентин

Алькесар

Josef Freinademetz