Select Page

Radware AppDirector – DNS Persistency

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 ( 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.

Default Value:


Updated Value:


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.

Enable 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 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 Normally this would be the IP address of the corresponding Layer 4 Policy.

DNS Action: Keep default value of Resolve

Create Host Name

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 get the IP address of and another entry forcing the clients on network get an IP address of

Example below depicts that users from a private, internal address receive an IP of while users from a public IP address receive an response of – = – = – – – – – = – – – –

Static DNS Persistency Table

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.

About The Author

Bryan Krausen

Bryan Krausen is currently working as a Sr. Solutions Architect with experience in a vast number of platforms, specializing in AWS and HashiCorp tools.


  1. Avatar

    Valuable notes about Radware AppDirector. Easily understandable blogs. Very few documents available on AppDirector.. Even their KB site is not able explained in such good manner. Thank you. Looking forwards more blogs on Citrix Netscaler or any other Cisco products.


Leave a reply

Your email address will not be published.