FQDN address object resolution (multiple IP's)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

FQDN address object resolution (multiple IP's)

L3 Networker

Hi

Can't seem to find more information besides the Administrator's guide v4.1 on this. I have two questions on this (FQDN address objects):

1) Security policies using a FQDN address object works great. Tested it by blocking access to certain websites. How does this method of blocking a website compare to using a custom URL profile?

2) Another question is regarding caching of the IP address(s) of the FQDN address object. What happens if the FQDN resolves with multiple IP addresses?

5 REPLIES 5

L4 Transporter

Hi Quinton,

I will try to answer for you:

1.  A lot of websites have multiple FQDN's - so you could be chasing your tail to cover all of these to block the relevant web sites.

2.  We can resolve up to 10 IP's per FQDN

Thanks

James

Let's say for example I want to block www.somewebsite.com. This website is not in the URL database. What would the difference be between creating a custom URL filtering profile, applying that to a security rule versus creating a FQDN address and setting that as the destination address in the security rule. Essentially the custom URL profile will have to do a DNS lookup as with the FQDN address right?

No...

When you use FQDN this is just an "alias" for src/dstip. Meaning that once you commit your security rule the PA device will do a DNS lookup to transform this FQDN (note: not to mistake FQDN with the name of the object which is different and isnt resolved) and once it figured out the ip address it will use that for your security rule when it compiles.

The PA will then (if im not mistaken) auto-commit every 30 minutes to get a fresh view of which ip your FQDN points to (according to DNS server).

In my opinion this is bad for several reasons. One is that your security rules can be altered by comromising your DNS server so it will respond with a different ip address for this particular FQDN (and hey - suddently you have a huge hole from Internet into some sensitive system on the inside).

When you create a custom url filtering then the url being requested will be analyzed as a textstring (because the client for a http request will send a request containing Host-header). Which is also not foolproof because the client can send a request based on the ipaddress instead like http://1.2.3.4 which of course wont match your url filter for *.example.com and example.com.

So best (if you want to block access) is to combine a url filter with an ip range. Or even better send this in as appid request if this is a public resource (or create your own custom appid) - or for that matter use all three methods in combination (dstip / url-filter / appid).

Its easier if you do the other way around - default block and only allow specific url-categories (and/or customer url filterings). This way if a client tries to use the ip to reach a website or some proxied request (in case that proxy is recognized as web-browsing by PA) it wont succeed.

Indeed. URL filtering can be bypassed using the IP address of the website in question. So to effectively block a specific website you'll have to use a combination of destination IP (or FQDN address object) and a custom URL filtering profile.

Does anybody know what CLI command can be used to check the current DNS cache for the FQDN address objects?

request system fqdn show

shows the FQDN its ip-address the remaining TTL and the seconds since the last refresh

  • 10562 Views
  • 5 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!