Create a split-DNS for AD forest with same AD-domain name and DNS-domain name

 This is useful for a lab environment where you have an AD forest uses same domain name AD-wise and DNS-wise

• Set up
• domain name: foo.bar
• internal subnet: 192.168.0.0/24
• Commands
• Add-DnsServerClientSubnet -Name "loopback" -IPv4Subnet 127.0.0.0/24
  Note: don't forget to add loopback as internal subnet 
• Add-DnsServerClientSubnet -Name "internal" -IPv4Subnet 192.168.0.0/24
• Add-DnsServerZoneScope -ZoneName "foo.bar" -Name "internet"
• Add-DnsServerResourceRecord -ZoneName "foo.bar" -A -Name "@" -IPv4Address "yourPublicIP" -ZoneScope "internet"
• Repeat above to add other A records that needs a public internet presence
• Add-DnsServerResourceRecord -ZoneName "johnfoo.tk" -name "@" -NameServer "yourPublicIP" -NS -ZoneScope "internet" (Optional, your DNS provider already knows how to find your name server)
• Add-DnsServerQueryResolutionPolicy -Name "NonInternalPolicy" -Action ALLOW -ClientSubnet "ne,Internal,loopback" -ZoneScope "Internet,1" -ZoneName "foo.bar"
• Add-DnsServerResourceRecord -ZoneName "johnbook.ga" -name "@" -TXT -DescriptiveText "MS=ms35639551" -ZoneScope "internet" 

What is DNS DNAME record and how it works

 

2 TTL related registry on Windows client OS

1. Maximum time a client will cache positive results regardless what TTL a record holds:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters\MaxCacheEntryTtlLimit

Note: A record will be cache on client for the period specified in

• record TTL or
• above registry value, whichever is less. 

2. When register its own record, the TTL sent to DNS server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DefaultRegistrationTTL

See Also

• Negative results are cached very differently. Please see Negative cache TTL on Windows-based DNS
• DNS Zone intervals - mapping values in Windows GUI to nslookup result for SOA record
  

DNS Zone intervals - mapping values in Windows GUI to nslookup result for SOA record

 
See above, click to see enlarge picture.

This is a screenshot of SOA record.

What the intervals are:

• (Most important one) Minimum default TTL: Default TTL for all records in the zone that don't have their own TTL defined during creation. This parameter is also used as TTL of negative cache
• TTL : TTL for the SOA record itself
• Refresh - This is how often (in seconds) the slave name servers check with the primary name server to see if any changes have been made to the zone
• Retry - This is the time (in seconds) a slave (secondary) DNS server waits before retrying a failed zone transfer
• Expires  - Indicates when the zone data is no longer authoritative - time counted from the point when slave loses contact with master. Applies to Slaves or Secondary servers only. When this expires, slave will no longer respond to queries

Update #1: Regarding negative caching, it is lesser of  Minimum Default TTL, SOA TTL, and 15min (defined in MaxNegativeTTL,  can be viewed with powershell cmdlet get-dnsservercache)

Update #2: One can set different values on SOA TTL and Minimum Default TTL, but Windows will set both to same value, whichever is smaller. Tested on Windows 2016

Negative cache TTL on Windows-based DNS

Think about this scenario:

- client uses Windows DNS for name resolution
- client has a record on an external DNS server, let's say a.external.com
- Windows DNS forwards queries of *.external.com to its respective authoritative DNS
- a.external.com has a TTL of 1 min
- a.external.com is removed then re-created with a new IP in 2 min time range (this is common for a cluster or load balancer setup)
- After the record is re-created, client pings it right away and expect to see new IP returned
- Actual result is "host name not found in DNS"

This is because how Windows DNS handles negative cache. Within that 2 min outage window, if anyone queried the name, Windows DNS gets a negative result from upstream (external) DNS. This negative result is cached ( naturally called negative caching), with a TTL as described below:

• Windows client resolver has a universal negative cache time (default 5 min) that can be changed in registry
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \DNSCache\Parameters\NegativeCacheTime
• Windows DNS server sets the TTL of negative result cache from SOA of hosting zone (update: lesser of TTL for SOA record itself, or the zone Minimum Default TTL). In this particular case, TTL from external.com zone SOA. However when SOA TTL is too short (<1min) or too long (>15min), Windows will cap TTL to be 1min and 15 min respectively(Coming from MaxNegativeTTL, can be viewed by powershell cmdlet get-dnsservercache).

See my other 2 posts on TTL/negative cache

(positive) TTL client side registries
DNS Zone intervals - mapping values in Windows GUI to nslookup result for SOA record

More read:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc959309(v=technet.10)
https://social.technet.microsoft.com/wiki/contents/articles/26864.windows-server-dns-service-negative-caching.aspx
https://social.technet.microsoft.com/Forums/windowsserver/en-US/e5feb606-9eba-46aa-ac57-08a98f812071/negative-dns-caching?forum=winserveripamdhcpdns
Windows 2000 behavior about capping: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc959309(v=technet.10)?redirectedfrom=MSDN
Cannot find official article about new versions, but I assume globally it's regulated by MaxNegativeTTL

Replication error'ed out with "no more endpoints"

1.       When right click “replicate now”, and the error message is “error 1753: There are no more endpoints available from the endpoint mapper”, it’s complaining the source DC not able to find a RPC endpoint from target DC. To make it more confusing, these two DCs are replicating to all their other partners - they just don’t want to replication with each other (one direction)

2.       This KB helps: http://support.microsoft.com/kb/2089874 and with good explanation too

3.       In our case, it sounds like root DC(source) was brought to a wrong child DC (target) for replication as per above KB.

4.       However when I check all related A/CNAME records, they are all CORRECT. All WINS records are correct too. Clean DNS cache on both client side and DNS server side didn’t help either

5.       It turns out it’s child’s delegated zone in root zone has incorrect glue record (right click child zone, properties, name servers tab). Windows apparently is capable of detecting such misconfiguration but chose not to auto correct, which is weird. 

Lesson learned: when a DC's CNAME or A is resolved to a wrong IP while all its references in visible zones are correct, please check the Name Servers tab of stud node (of child zone) in parent DNS server. Also, when promote/demote child DCs, or change their IPs, please make sure changes are made in the Name Servers tab too ( I mistakenly assume that dcpromo program would do that automatically)