DNS Round Robin and Destination IP address selection
DNS Round Robin and Destination IP address selection
This post is meant to discuss the issues that can occur with Destination IP address selection and its affect on the DNS Round Robin process. What is Round Robin and Netmask Ordering DNS Round Robin is a mechanism for choosing an IP address from the list returned by a DNS server so that all clients won't get the same IP address every time. Netmask ordering is a mechanism for further optimizing which IP address is used by attempting to determine the closest result.
842197 Description of the netmask ordering feature and the round robin feature in Windows Server 2003 DNS
http://support.microsoft.com/default.aspx?scid=kb;EN-US;842197
The netmask ordering feature is used to return addresses for type A DNS queries to prioritize local resources to the client. For example, if the following conditions are true, the results of a query for a name are returned to the client based on Internet protocol (IP) address proximity:
* You have eight type A records for the same DNS name.
* Each of your eight type A records has a separate address.
The round robin feature is used to randomize the results of a similar type of query to provide basic load-balancing functionality. In the earlier example, eight type A records with the same name and different IP addresses cause a different answer to be prioritized to the top with each query. Because a new IP address is prioritized to the top with
each query, clients are not repeatedly routed to the same server. The key points here are that DNS Round Robin only provides a simple load-balancing system by alternating the IP at the top of the list the DNS server returns and that Netmask Ordering will return a list with the "closest" IP at the top of the list the DNS server returns. Both are server side mechanisms commonly used to provide simple load
balancing functionality.
Destination Address Selection
Destination address selection is how the client decides which destination IP address is selected when it gets a list of IP ddresses.
The netmask ordering feature is used to return addresses for type A DNS queries to prioritize local resources to the client. For example, if the following conditions are true, the results of a query for a name are returned to the client based on Internet protocol (IP) address proximity:
* You have eight type A records for the same DNS name.
* Each of your eight type A records has a separate address.
The round robin feature is used to randomize the results of a similar type of query to provide basic load-balancing functionality. In the earlier example, eight type A records with the same name and different IP addresses cause a different answer to be prioritized to the top with each query. Because a new IP address is prioritized to the top with
each query, clients are not repeatedly routed to the same server. The key points here are that DNS Round Robin only provides a simple load-balancing system by alternating the IP at the top of the list the DNS server returns and that Netmask Ordering will return a list with the "closest" IP at the top of the list the DNS server returns. Both are server side mechanisms commonly used to provide simple load
balancing functionality.
Destination Address Selection
Destination address selection is how the client decides which destination IP address is selected when it gets a list of IP ddresses.
IPv4: When using IPv4 only (Windows XP, Windows 2003 Server and prior),
destination address selection is fairly simple and done by selecting
the IP address at the top of the list that was returned by the DNS
server. This works well with DNS Round Robin as it lets the Server
decide what address the client will use by putting it at the top of the
list.
destination address selection is fairly simple and done by selecting
the IP address at the top of the list that was returned by the DNS
server. This works well with DNS Round Robin as it lets the Server
decide what address the client will use by putting it at the top of the
list.
IPv6: IPv6 introduces a change in this behavior per RFC 3484.
RFC 3484 Default Address Selection for IPv6 - http://www.ietf.org/rfc/rfc3484.txt
RFC 3484 Default Address Selection for IPv6 - http://www.ietf.org/rfc/rfc3484.txt
Destination Address Selection
The destination address selection algorithm takes a list of destination addresses and sorts the addresses to produce a new list.It is specified here in terms of the pair-wise comparison of addresses DA and DB, where DA appears before DB in the original list.The algorithm sorts together both IPv6 and IPv4 addresses....
The pair-wise comparison of destination addresses consists of ten rules, which should be applied in order. If a rule determines a result, then the remaining rules are not relevant and should be ignored. Subsequent rules act as tie-breakers for earlier rules. There are 10 rules, but it is rule 9 that we need to consider.
The pair-wise comparison of destination addresses consists of ten rules, which should be applied in order. If a rule determines a result, then the remaining rules are not relevant and should be ignored. Subsequent rules act as tie-breakers for earlier rules. There are 10 rules, but it is rule 9 that we need to consider.
Rule 9: Use longest matching prefix.
When DA and DB belong to the same address family (both are IPv6 or both are IPv4): If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then prefer DB.
Essentially this says that we should use the longest match and not just pull the first IP address off the list. The key point to understand is that there is a change in behavior by design when IPv6 is on the system and that when IPv6 is installed Windows does not just pull the first IP address off the list.The affect of RFC3484 on DNS Round Robin
When Vista clients (or XP clients with IPv6 installed) query DNS and receive a list of IP addresses, a destination selection algorithm kicks in and returns the destination address that has the longest prefix match (per RFC3484). This breaks the DNS server's site load balancing as follows. In the case of Round-Robin this means we can't count on the randomization provided by the DNS server.
When DA and DB belong to the same address family (both are IPv6 or both are IPv4): If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then prefer DB.
Essentially this says that we should use the longest match and not just pull the first IP address off the list. The key point to understand is that there is a change in behavior by design when IPv6 is on the system and that when IPv6 is installed Windows does not just pull the first IP address off the list.The affect of RFC3484 on DNS Round Robin
When Vista clients (or XP clients with IPv6 installed) query DNS and receive a list of IP addresses, a destination selection algorithm kicks in and returns the destination address that has the longest prefix match (per RFC3484). This breaks the DNS server's site load balancing as follows. In the case of Round-Robin this means we can't count on the randomization provided by the DNS server.
Example:
A client with an IP address of 192.168.0.1 queries for Webserver.test.net and receives the following list:
Webserver.test.net A 192.168.1.10
Webserver.test.net A 192.168.5.20
Webserver.test.net A 192.168.6.30
Webserver.test.net A 192.168.0.40
Webserver.test.net A 192.168.4.50
With RFC3484 in effect, the client will always use the 192.168.0.40
address as it is the longest match, negating the effects of DNS round-Robin.
In the case of NetMask Ordering, if some server’s address is “closer” to the client address and would be preferred, it will always get that address.
A client with an IP address of 192.168.0.1 queries for Webserver.test.net and receives the following list:
Webserver.test.net A 192.168.1.10
Webserver.test.net A 192.168.5.20
Webserver.test.net A 192.168.6.30
Webserver.test.net A 192.168.0.40
Webserver.test.net A 192.168.4.50
With RFC3484 in effect, the client will always use the 192.168.0.40
address as it is the longest match, negating the effects of DNS round-Robin.
In the case of NetMask Ordering, if some server’s address is “closer” to the client address and would be preferred, it will always get that address.
Example:
A client with an IP address of 192.168.0.1 queries for Webserver.test.net and receives the following list:
Webserver.test.net A 192.168.0.100
Webserver.test.net A 192.168.0.10
Webserver.test.net A 192.168.0.11
Webserver.test.net A 192.168.0.15
Webserver.test.net A 192.168.0.20
With RFC3484 in effect, the client will always use the 192.168.0.10
address as it is the longest match, negating the effects of netmask ordering. You can see why by looking at the 4th octet in binary. You compare bits until you reach one that doesn't match.
A client with an IP address of 192.168.0.1 queries for Webserver.test.net and receives the following list:
Webserver.test.net A 192.168.0.100
Webserver.test.net A 192.168.0.10
Webserver.test.net A 192.168.0.11
Webserver.test.net A 192.168.0.15
Webserver.test.net A 192.168.0.20
With RFC3484 in effect, the client will always use the 192.168.0.10
address as it is the longest match, negating the effects of netmask ordering. You can see why by looking at the 4th octet in binary. You compare bits until you reach one that doesn't match.
With a client IP address of 192.168.0.1, the comparison is 00000001.
11000000 10101000 00000000 00000001 = 192.168.0.1 = Client IP to match.
11000000 10101000 00000000 01100100 = 192.168.0.100 = (24 + 1 = 25 bits matching the client IP)
11000000 10101000 00000000 00001010 = 192.168.0.10 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001011 = 192.168.0.11 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001101 = 192.168.0.15 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00010100 = 192.168.0.20 = (24 + 3 = 27 bits matching the client IP)
Then the first entry from the longest match is chosen. In this case, 192.168.0.10.
An Alternative
You can change the behavior on Windows Vista SP1 and Windows Server
2008 with a client side registry entry documented in KB 968920.
Note: Windows 7 and Windows Server 2008 R2 will change the default behavior.
968920 Windows Vista and Windows Server 2008 DNS clients do not honor DNS round robin by default
http://support.microsoft.com/default.aspx?scid=kb;EN-US;968920
Symptom
By default, Windows Vista and Windows Server 2008 follow RFC 3484
for destination IP address selection, which does not honor DNS round robin.
Resolution
To resolve this issue, add a registry key that disables subnet prioritization.
Add a new registry key with the following settings:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DWORD = OverrideDefaultAddressSelection
Value data: = 1
11000000 10101000 00000000 00000001 = 192.168.0.1 = Client IP to match.
11000000 10101000 00000000 01100100 = 192.168.0.100 = (24 + 1 = 25 bits matching the client IP)
11000000 10101000 00000000 00001010 = 192.168.0.10 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001011 = 192.168.0.11 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00001101 = 192.168.0.15 = (24 + 4 = 28 bits matching the client IP)
11000000 10101000 00000000 00010100 = 192.168.0.20 = (24 + 3 = 27 bits matching the client IP)
Then the first entry from the longest match is chosen. In this case, 192.168.0.10.
An Alternative
You can change the behavior on Windows Vista SP1 and Windows Server
2008 with a client side registry entry documented in KB 968920.
Note: Windows 7 and Windows Server 2008 R2 will change the default behavior.
968920 Windows Vista and Windows Server 2008 DNS clients do not honor DNS round robin by default
http://support.microsoft.com/default.aspx?scid=kb;EN-US;968920
Symptom
By default, Windows Vista and Windows Server 2008 follow RFC 3484
for destination IP address selection, which does not honor DNS round robin.
Resolution
To resolve this issue, add a registry key that disables subnet prioritization.
Add a new registry key with the following settings:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
DWORD = OverrideDefaultAddressSelection
Value data: = 1
Comments