Maybe I misunderstand the question, but the answer is simple: you need to register a SRV record in the zone (mydomain.com) for the dc's entries. It will tell the clients where to find the DC.
Something along the lines of
_ldap._tcp.dc._msdcs IN SRV 0 100 389 hostname-of-dc.mydomain.com.
Use at a Split DNS configuration in bind. You should be using this anyway to prevent the use of your bind server in amplification attacks. Once you have that running you proceed to a split configuration of your zone file.
Create a zone file for intranet (internal) users and another for Internet (external) users. Place only sub-domains that have different IP addresses in each file. Create a third file containing the rest of the IP addresses and include it in the first two zone files. I would place the serial number in the include file.
Using this configuration you will be able to edit in one place and reload. If you need to change the IP address of one of the servers which has different IP addresses for local and Internet users, you will need to increment the serial number in the third file.
The above approach may leak information about servers you don't want reachable from the Internet. You may be better using two zone files, one for intranet users, an the second for the Internet. If you plan your network well, IP addresses should only need to be changed in one file at time.
The zone file for the Internet should only contain information on domains you want to access from the Internet. It should only include Internet routeable IP addresses.
The zone file for the intranet can contain all the servers you want. It can include servers with private IP addresses: 10.0.0.0/8, 172.16.0.0/12, and/or 192.168.0.0/8. If you use a VPN, configure your split DNS to include VPN hosts on the intranet size.
EDIT: Work really hard at stabilizing the IP addresses visible on the Internet. I have yet to work on a project where they were dynamic. You really should have as few domains as possible visible from the Internet. They should all reside within a DMZ. If possible, multi-home IP address for domains that move frequently. If not, consider creating a sub-domain on the internet side where you change the IP addresses and use CNAMES to point to these records from both the Internet and intranet.
Server/services that must be exposed to the Internet include DNS, Web, SMTP (Mail), and VPN. Carefully consider the risk for other servers/services. (Multiple) Web domains are easily handled with CNAMES. In most cases, database servers should not be exposed to the Internet.
Best Answer
That's out of date for current technology. In the BIND world, Response Policy Zones (RPZ) are synonymous with DNS firewalls these days.
A RPZ zone is a normal DNS zone, but is used to define policy actions by the server. The zone "suffix" does not matter, as this is not a real DNS domain. It's simply a zone file that contains a list of specially formatted instructions.
The left hand side of the record defines the matching rule, with the record type and right hand side defining the action to take. Note the absence of a trailing dot on the left hand side of the following examples.
And so on. You can do quite a bit with this, including more heavy handed measures that risk impacting innocent shared hosting sites: blocking nameservers by name, blocking nameservers by IP, performing actions on the IP address of a returned record instead of the name, etc.
There's a lot that RPZ will do, and this isn't meant to serve as exhaustive documentation. Recommended reading include the Chapter 6 of the BIND ARM (bottom of this answer) for your version of BIND, and Chapter 9 of the online Zytrax book.
Cliff notes from my personal experience to save you time:
IXFR
. Enableixfr-from-differences
on your master to facilitate this. Use key based zone transfers if using BIND 9.9 or later to protect against NOTIFY based DoS attempts.NS
record based attacks that became popularized in 2014, as by default RPZ is designed to attempt authoritative lookups and not "betray" your record hijacking to an upstream nameserver source.qname-wait-recurse no
was added in BIND 9.10 and may allow you to use RPZ for this purpose. I've been meaning to lab it out.qname-wait-recurse no
works, there is still a need for a record type that can be used to offline attack domains without extra configuration. I've spoken to Paul Vixie about this and we may see it in a future version of the RPZ format spec.NXDOMAIN
andNODATA
actions will betray the name of your RPZ zone in theAUTHORITY
section of the reply. Assume that people will learn its name.BIND ARM Chapter 6 links: