Radware AppDirector – DNS Persistency
During the deployment of GSLB, the requirement for AppDirectors become a DNS server started to pose a security issue for us. Our GSLB deployment not only guaranteed up-time for our externally available applications but also applications which were meant only for internal consumers as well. However, because we were still required to utilize the AppDirector for internal DNS, we quickly discovered that public nslookups against the AppDirectors would display the private IP for the internal-only application records. Although it would require “inside knowledge” to gain the URL, it still presented a problem for us.
The solution? Static DNS Persistency
Static DNS persistency operates at the farm level and is based upon the client IP address. This means that you can have multiple clients requesting an IP address for the same host (www.abc.com) and warrant different results. For example, if you wanted clients from subnet A to get a different result from clients in subnet B, you can use the DNS persistancy table to accomplish this. The following depicts how this is setup:
Services –> Tuning –> Device
The first step to utilizing DNS Persistency is to modify the table size on the device. Radware ships the AppDirector with a default table size of 5, meaning that it can store up to 5 static DNS entries. Attempts to add additional entries above the table size will result in the error: “Status: Unable to set static dns“. In the device tuning page, find the entry named “Static DNS Persistency Entries” and note the current value. Modify the value by changing the field on the right named “Static DNS Persistency Entries After Reset” and click Set.
As with any device tuning changes, you need to verify that the device has the available memory to allocate to the expanded table. This eliminates the chance of a memory problem (shortage?) upon reboot. Do this selecting Memory Check at the top or by navigating to Services –> Tuning –> Memory Check. Once it gives the all clear, you must reboot the AppDirector for the changes to take effect.
AppDirector –> Farms –> DNS Persistency Parameters
The next step to utilizing DNS Persistency is to enable it on the farm – remember that DNS Persistency operates at the farm level. To do this, go to AppDirector –> Farms –> DNS Persistency Parameters and enable both Status and Static Mode. Static enables DNS persistency and Static Mode enables Static DNS Persistency.
AppDirector –> DNS –> Host Names
The next is to create a DNS entry for our URL.
Host Name: URL clients will be looking for (think A record here)
L4 Policy Name: Select the relevant Layer 4 Policy that users will be connecting to here.
Farm Name: Select the relevant Farm that will be servicing this request.
External NAT Address: For this example, static DNS persistency, leave as 0.0.0.0. Normally, as seen on my post about GSLB, you would put the public IP address if NAT’ed from a device upstream.
Preferred Resolve IP: For this example, static DNS persistency, leave as 0.0.0.0. Normally this would be the IP address of the corresponding Layer 4 Policy.
DNS Action: Keep default value of Resolve
AppDirector –> DNS –> Persistency Table
Last, but not least, it’s time to make changes to the actual Static Persistency Table. The entries consist of 3 key components: Farm, IP Range that entry applies to, and the IP address you wish to hand out. This provides the admin with flexibility in terms of who gets what IP address. For example, you can have an entry that clients on 10.0.1.0/24 get the IP address of 220.127.116.11 and another entry forcing the clients on network 10.0.2.0/24 get an IP address of 18.104.22.168.
Example below depicts that users from a private, internal address receive an IP of 10.0.0.1 while users from a public IP address receive an response of 22.214.171.124.
0.0.0.1 – 126.96.36.199 = 188.8.131.52
10.0.0.0 – 10.255.255.255 = 10.0.0.1
184.108.40.206 – 220.127.116.11 – 18.104.22.168
172.16.0.0 – 172.31.255.255 – 10.0.0.1
22.214.171.124 – 126.96.36.199 = 188.8.131.52
192.168.0.0 – 192.168.255.255 – 10.0.0.1
184.108.40.206 – 255.255.255.255 – 220.127.116.11
Keep in mind that any IP addresses you want to utilize in the Preferred VIP section must be added to the AppDirector as either the IP of a Layer 4 Policy or a IP address of the farm’s server configured as a type Remote Server, Distributed Server, or Local Farm.