Performing Local Testing in preparation for Oracle Dyn (formerly Zenedge) WAF/DDoS Platform Deployment

Before you alter your DNS zone file to direct traffic for your web servers to pass through the Oracle DYN (formerly Zenedge) platform, you need to be confident that the platform will process that traffic as you expect.

This will verify

  • that the platform is configured to handle your traffic
  • that the platform can correctly access pages from your Origin Servers
  • that your application works as expected when passed through the platform
  • that your SSL traffic is handled with the correct and appropriate certificate
  • that you are familiar with the features of the dashboard and the portal

Local testing can be done using a specific Hosts file entry to the Zenedge supplied specific IP address which the activereach support team will provide to you, or by using an internal DNS server with the target FQDN resolving to either the IP address we have provided to you or the portal visible CNAME.

Make sure that if you have a corporate proxy server that your test machine bypasses this or you will have the live non-Zenedge provided web server pages returned.

This may also be true if you are using PAC files or any other modification to your browser to direct it to a proxy server.

Additionally watch for anything that redirects HTTP requests like the ‘HTTPS Everywhere’ Chrome plugin or system level proxy plugins (such as the Webroot DWP).

Note that your new Web App will be listed as ‘Offline’ in the portal until your have redirected DNS for your site to point at Zenedge. You will see this in the ‘Status’ column for the relevant Web App:


The status will change to ‘Online’ (checks are made once an hour) after you have completed ‘local testing’ and altered your DNS to send live traffic to the Zenedge platform – this is when you are confident that the portal is handling your web requests as you expect.

Modifying Your HOSTs File

Alter the hosts file to point to the Zenedge specific IP address (because you can’t point to the CNAME in a hosts file). You can get the specific address for your Web App from your portal or by asking by activereach support team.

Details of how to edit your hosts file can be found at though if you are using OSX these instructions are better –

Note that your anti-virus software might prevent you from making changes to your hosts file. We have seen this behaviour with Avira but it may also be present in other AV applications.

You may also find our technical tutorial video for this will help.

Confirming Passage Through Zenedge

Access your web site and you can tell whether the traffic has come back from the Zenedge proxy if you look at the returned HTML headers as you will see

X-Cdn: Served_By-_Zenedge

Details on how to see this in Chrome:

  1. View/Developer/Developer Tools/Network and reload the page
  2. Select the request in “Network” tab for which you want to see the headers
  3. Select “Headers” tab on the right pane
  4. You can see HTTP headers for the request

Details of how to see this in Firefox:

  1. Use Tools/Web Developer/Network and reload the page
  2. Select the element for which you want to see the headers
  3. The HTTP headers are displayed for that element on the right-hand side

A model example is shown below, note the highlighted lines:

Request URL:
Request Method:GET
Status Code:200 OK
Remote Address:
Response Headers

Date:Wed, 13 Jan 2016 17:15:12 GMT
Expires:Wed, 13 Jan 2016 18:15:12 GMT
Last-Modified:Fri, 05 Jun 2015 11:25:46 GMT

If you see no reference to Zenedge in the headers, then the page is not being served via Zenedge and it is not safe therefore to make any DNS changes until this is rectified and confirmed.

If you cannot access the features in your browser to check the HTTP headers, you may be able to use a site like to do this.

Things to check

Watch for Origin Lockdown if the server is behind a load balancer. This stops the server responding to Zenedge because it expects to only speak to the load balancer. In this case we need to have the Zenedge IPs added to the relevant ACL.

You should test for all possible FQDNs that you may use to pass traffic to that Origin Server, typically this will be at least and for example, but it might include others like etc

Note that if at the start of local testing you see one of your other corporate web sites rather than one you expected, we often find that you have not listed the correct Origin Server in the Web App you are testing. This is in the ‘Settings/Name and Domains’ part of the portal:


The platform uses the Host Header part of the URL you use to determine which Web App definition, and therefore which Origin Server, it should use to retrieve the page you request.

You should also test using HTTPS if you expect your website or web application to be served over an SSL connection.

In general, we advise you to do your local testing in conjunction with activereach support staff (which may require you to have a purchased support plan) so that there is confirmation from wholly outside your corporate network that your pages are being served via the Zenedge platform. In particular SSL based sites can fail in a variety of complicated ways based on the combination of certificate, browser, platform, and scripting.

Testing potential changes to a live Web App

You can do the equivalent of Local Testing for a live/online Web App by using the Staging service. This provides a duplicate of the live environment and a specific access address so you may test changes without affecting the live production service Web App.

You can tell which of your Web Apps is the staging version because the dashboard will show it with the staging icon displayed below:


Checking traffic passage through Zenedge for live Web Apps

If you need to check that a Zenedge defined Web App is actually receiving traffic when you have moved your DNS entry to point to Zenedge, you can use our Confirming Web App Service page.