A DNS deployment is said to be split-brain
(or split-horizon) when there are two versions of a single zone, one
for the internal users and one for the external users – typically users
on the public internet. For Windows DNS server based deployments, such
scenarios called for maintaining two different DNS servers, each
catering to a different set of the users. If only a few records inside
the zone were split brained or both instances of the zone (internal and
external) were delegated to same parent domain this became a management
conundrum.
Another
variant of the split brain deployment is the selective recursion
control for DNS name resolution. Sometimes the enterprise DNS servers
are expected to perform recursive resolution over internet for the
internal users; while they have to act as a pure name servers
(authoritative) for external users and block recursion for them. Here we
shall see how these two scenarios can be accomplished using DNS
policies.
Two versions of the same zone
Suppose the career website of contoso.com is hosted at www.career.contoso.com
. The site has two versions, one for the internal users where internal
job postings are available and is available on a local IP 10.0.0.39. The public version of the same site is available on public IP 65.55.39.10.
In absence of DNS policies, the administrator had to host these two
zones on separate Windows DNS servers and manage them separately. Using
DNS policies these zones can now be hosted on the same DNS server.
If the nameserver hosting contoso.com zone is listening on two network interfaces; one with a public IP of 208.84.0.53 for external queries and another with a private IP 10.0.0.56 for internal queries then the administrator can follow these steps to achieve this split brain deployment
* All IPs and names are purely representational
Create the Scopes of the Zone
Partition the zone contoso.com to create an internal zone scope. A zone scope
is a unique instance of the zone. A DNS zone can have multiple zone
scopes, with each zone scope containing its own set of DNS records. The
same record can be present in multiple scopes, with different IP
addresses.
Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "internal"
Explore Add-DnsServerZoneScope
By
default a zone scope exists on the DNS zones. This zone scope has the
same name as the zone and legacy DNS operations work on this scope. This
default zone scope will host the external version of www.career.contoso.com
Add Records to the Zone Scopes
The next step is to add the records representing the web server host into the two zone scopes- internal and default (for external clients). In internal, the record www.career.contoso.com is added with IP address 10.0.0.39, which is a private IP; and in default zone scope the same record (www.career.contoso.com) is added with IP address 65.55.39.10.
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "65.55.39.10"
Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "10.0.0.39” -ZoneScope "internal"
Explore Add-DnsServerResourceRecord
Note
that no –ZoneScope parameter has been provided when record is being
added in default zone scope. This is same as adding records to a vanilla
zone.
Create the Policies
Once
the server interfaces for external network and internal network have
been identified; and the partitions (zone scopes) have been created, the
next step is to create policies that connect these two, in a way that
when the query is received on private interface, the answer is returned
form the internal scope of the zone. No policies are required for mapping default zone scope.
Add-DnsServerQueryResolutionPolicy
-Name "SplitBrainZonePolicy" -Action ALLOW -ServerInterface
"eq,10.0.0.56" -ZoneScope "internal,1" -ZoneName contoso.com
* 10.0.0.56 is the IP on the private network interface.
How it all works
Now
the DNS server has been configured with the required policies. When a
name resolution query is incident on the DNS server so configured, each
name resolution request is evaluated against the policies on the DNS
server. If the server interface on which the query has been received
matches any of the policy, the associated zone scope is used to respond
to the query. So, in our example, the DNS queries for www.career.contoso.com
that are received on from private IP (10.0.0.56) are responded with an
internal IP address; and the DNS queries that are received on the
public network interface are responded with the public IP address in the
default zone scope (this is same as normal query resolution).
Selective Recursion Control
In
the previous example, the same DNS server is serving both the external
and internal clients and respond back with different answers. Certain
deployments may require the same DNS server to perform recursive name
resolution for the internal clients apart from acting as authoritative
nameserver for contoso.com. For this, the recursion has to be enabled on
the DNS server. But as the DNS server is also listening to the external
queries, the recursion is also enabled for external clients and the DNS
server becomes what is known as an open resolver. This makes the server
vulnerable to resource exhaustion and can be abused by malicious
clients to create reflection attacks.
There is no reason why contoso.com’s DNS server should perform
recursive name resolution for external clients. Essentially there is a
need of recursion control such that the recursion is allowed for
internal clients while blocked for external clients.
This can be achieved in following steps
Create Recursion Scopes
Recursion
scopes are unique instances of a group of settings that control
recursion on a DNS server. A recursion scope contains a list of
forwarders and specifies whether recursion is enabled. A DNS server can
have many recursion scopes.
The
legacy recursion setting and list of forwarders are now referred as the
default recursion scope. You cannot add or remove the default recursion
scope, identified by the name “.” (Dot).
In
this example, the default recursion setting is being disabled, while a
new recursion scope for internal clients is being created where
recursion is being enabled.
Set-DnsServerRecursionScope -Name . -EnableRecursion $False
Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True
Create Recursion Policies
DNS
server recursion policies can be created to choose a recursion scope
for a set of queries matching certain criteria. If the DNS server is not
authoritative for those queries, these policies allow admin to control
how to resolve those queries. Here the internal recursion scope which
has recursion enabled is being associated with private network interface
Add-DnsServerQueryResolutionPolicy
-Name "SplitBrainRecursionPolicy" -Action ALLOW -ApplyOnRecursion
-RecursionScope "InternalClients" -ServerInterfaceIP "EQ,10.0.0.39"
In both the examples ServerInterface
has been taken as a criteria. Sometimes the split-brain may be required
to be deployed on the basis of source client subnet. That can also be
achieved using the client subnet criteria. (See how to use client subnet for traffic management)
How it all works
If a query for which the DNS server is non-authoritative is received, i.e. say for www.microsoft.com,
then the name resolution request is evaluated against the policies on
the DNS server. As these queries do not fall under any zone, the zone
level policies (as defined in first case above) are not evaluated. The
recursion level policies are evaluated and those queries which are
received on private interface match the SplitBrainRecursionPolicy
which points to a recursion scope where recursion has been enabled. The
DNS server then performs recursion to get the answer for www.microsoft.com
from internet and caches it locally. On the other hand if the query is
received on the external interface, no policies match and default
recursion setting (in this case disabled) is applied, preventing the
server from acting as open resolver for external clients while it is
acting as a caching resolver for internal clients.
No comments:
Post a Comment