topic Re: FQDN and DNS failure in General Topics

FQDN and DNS failure

blwallace — Thu, 26 Jan 2012 22:05:41 GMT

I'm looking to use FQDNs inside Address Objects but have some reservations. What happens if my DNS goes down, or becomes corrupted for some reason. In other words, when using FQDNs, what happens if the PA can't resolve the address? Is all traffic to FQDN configured objects blocked?

As an example, let's say access to my DNS server (or some other critical device) is through a rule with an address object of FQDN and not IP. Since I know the IP address of my DNS server, would I be able to SSH to it through an IP call or am I totally blocked until DNS comes back online? If true, I would need a separate rule to allow traffic by IP Netmask to my DNS server just in case DNS goes down and I need to gain access to my server to troubleshoot any problem?

Another example would be use FQDN for my email servers. If DNS goes missing, does all email stop?

Thanks,

Bart

Re: FQDN and DNS failure

mikand — Thu, 26 Jan 2012 22:40:19 GMT

If im not mistaken FQDN rules are resolved when the ruleset is committed and not dynamically.

Also note that the ruleset can be automatically committed if you have "download-and-apply" threat preventation and/or url-category database updates (usually once or twice a day).

Generelly its bad to use FQDN for firewalls mainly because you will then rely on some external information.

Let us assume you setup a rule which looks like:

srcip: any
srcport: >1023
dstip: mail.example.com
dstport: any

And then let us assume someone dns poision the dns-server your firewall is using when committing the rules so mail.example.com resolves into "0.0.0.0" (or even worse hacks your dns-server to manually setup the zones). Or for that matter if the dns-server is unavailable when you commits the ruleset - is the default in the firewall "0.0.0.0" for unresolved addresses or is it "255.255.255.255" (or will it even commit)?

The result would then be that you allow the current port and/or app-id to EVERY ip-address available for that particular zone (or even worse if you select zone:any).

If you want to setup rules towards your email servers we can be pretty sure you already use static ip's for those servers and therefor your have another reason for why you shouldnt use FQDN (because there is simply no need to).

You can setup local names in the firewall if you go to Network -> Address objects (and even Address Groups) to setup stuff like:

Address objects:

mail1.example.com (1.1.1.1)
mail2.example.com (2.2.2.2)

Address group:

Mailservers (mail1.example.com, mail2.example.com)

The above will point to the address objects named mail1. and mail2. NOT the FQDN). Or if you think you could be confused if its FQDN or not then just:

Address objects:

mail1 (1.1.1.1)
mail2 (2.2.2.2)

Address group:

Mailservers (mail1, mail2)

and then setup the rule as (just an example, in real life one would choose designated port along with zone AND app-id etc):

srcip: any
srcport: >1023
dstip: Mailservers
dstport: any

Re: FQDN and DNS failure

blwallace — Thu, 26 Jan 2012 23:02:29 GMT

If I understand you correctly, the FQDN in regards to function, is really an alias - meaning, the FQDN is resolved at rule commit and the firewall then holds the IP address of the resolve action to manage the traffic defined within the rule.

Your example, mail1.example.com is a FQDN, but you state the firewall uses 1.1.1.1 as the real address of the object and not an nslookup each time the rule is hit.

Correct?

Re: FQDN and DNS failure

mikand — Thu, 26 Jan 2012 23:25:55 GMT

If you setup an address object such as:

mail1 (mail1.example.com)

and use this in a rule the FQDN will be resolved during commit and the ip address which mail1.example.com points to according to the dns-server used will be used.

Like so:

1) You click commit

2) The PAN will replace the names of each address object with the content each address object refers to (mail1.example.com for above example).

3) Next the PAN detects that you use FQDN so it will need to resolve mail1.example.com (lets say into 1.2.3.4) by query your dns-server.

4) The PAN will (hidden from you) "rewrite" the rule so "1.2.3.4" will be actually written to the hardware (FPGA's).

Now, if you use address objects which points to ip-addresses (instead of FQDN) there is no need to query external dns-server.

Example:

Address object:

mail1 (1.1.1.1)

During commit the following will then happen:

1) You click commit.

2) The PAN will replace the names of each address object with the content each address object referes to (1.1.1.1 for above example).

3) Since you have no FQDN's at this stage the PAN wont need to perform any dns-queries.

4) The PAN will (hidden from you) "rewrite" the rule so "1.1.1.1" will be actually written to the hardware (FPGA's).

Re: FQDN and DNS failure

blwallace — Fri, 27 Jan 2012 15:29:18 GMT

Thank you, that helps.