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 https://1.2.3.4
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 example.com may require that you add the IP Addresses of example.com 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, navigate to Tools > Trace Request. Enter the IP of the website into the URL field, for example https://1.2.3.4
- 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 Logs and select the Advanced Filter button. Enter the IP of the workstation into the IP the Client IP Filter Field and apply the filter.
- 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 Logs. Is there a subdomain that is being allowed that should be blocked?
- Enter the new subdomain URL into a Deny List.
- Test the new entry using the Trace Request tool (as described earlier in this document) 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.
Will a List rule for example.com cover all IPs for that domain?
i.e., www.example.com and news.example.com
There may be a different IP for example.com and for www.example.com and for news.example.com. 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.