How can we help?

How does the RDNS work when filtering HTTPS in Netsweeper?


RDNS and HTTPS Overview

The Netsweeper Policy Service feature for Reverse DNS (RDNS) filtering is used to map requests to IP addresses back to the hostname associated with the specific IP address.  This allows the Policy Service to perform filtering actions that include:

1.      HTTPS filtering when Server Name Information (SNI) is not present and the request to the Policy Service is in the format

2.      Eliminating the possibility of bypassing filtering by accessing the specific IP Address of a remote site that is denied by the hostname

3.      Eliminating the need to add multiple list entries to deny a single site.

a)      For example: Prior to RDNS, blocking may require that you add the IP Addresses of to the specified list depending on the protocol used to access the remote site.

IP addresses in policy requests and log files show up for one of two reasons:

1.      A request is for a protocol other than HTTP, meaning the product cannot easily get the hostname and therefore the request is based on the IP.  This is the case for HTTPS requests without Server Name Information (SNI).

2.      When a user visits a site, clicks a link, or visits a page using a URL resource that has an IP in it instead of a hostname.  Users may do this to bypass the filtering solution.

The Policy Service includes a table to map IP addresses back to the hostnames associated. This is called the RDNS Cache. This cache is managed by the Policy Service and populated via a number of methods. This cache takes time to load and reload, on a fresh install of the policy server it may take 30 to 45 minutes to fully populate this RDNS Cache.  On the restart of the policy server is may take up to five minutes to load and reload.   Therefore, it is important to know and understand how to test the operation of this RDNS cache.


Testing RDNS

To check to see if the RDNS has loaded, use the URL Tools > Trace URL Request. Enter the IP of the website into the URL field, for example


If you see a Reverse DNS lookup the RDNS is working as shown in the above screen shot. If you don't see Reverse DNS as the first step then your RDNS has not yet populated (as below).


Keep sending the request and once the RDNS has populated, the screen should change to reflect the populated RDNS (as below).


If the Trace URL tool does not have the Reverse DNS lookup. Testing in a browser will fail and the site will be allowed.  Once you see the reverse DNS entry you are ready to test in a browser.

If your browser test fails then there are other entries required to fully block the URL.  To determine what other URLs may be needed, follow the process below.


Finding Additional URLs

Have a test workstation setup that is being filtered by the policy server.

Open the WebAdmin > Logs > Request Log Files and click the Advanced button. Enter the IP of the workstation into the IP the Client IP Filter Field and click the Filter button.

On the test workstation, in a browser, empty the browser cache then go to the URL that is failing to be blocked.

Switch over to the the WebAdmin window and look at the Request Log Files. Is there a subdomain that is being allowed that should be blocked?

Enter the new subdomain URL into the deny list test the new entry using URL Trace Request as above to make sure the IP has been populated in the RDNS.  Test with the workstation again making sure that the browser cache is dumped prior to testing.

If testing fails again, follow through the process again to find what other URLs may require blocking.

If I enter, doesn't that cover all IPs from and

There may be a different IP for and for and for All of these variations must be in the deny list for the RDNS to populate with the IP for that each host to fully block the site.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request