Using FQDNs pointing to a CNAME instead of A Record does not work

[rkra]

My PA can not resolve FQDNs pointing to a CNAME.

This is dangerous, if you are using FQDN instead of IPs in policies. They can stop working.

We configured a FQDN hostname host.mydomain.de and bound it to a policy.

Few months later moved this Service to another server using CNAME.

host.mydomain.de. CNAME newhost.mydomain.de

PA can not resolve this new IP for hot.mydomain.de and the policy stops working.

Is there a way to prevent this?

Roman

[hshah]

Hi Roman,

You are supposed to create FQDN address object for "host.mydomain.de.".

Use Address-Object in Policy.

Firewall resolves this FQDN objects frequently, that way your policies remain up to date.

Let me know if this helps.

Regards,

Hardik Shah

[rkra]

Hi Hadrik,

the address Object was already created and worked as long there was a A RECORD in the DNS.

host.mydomain.de  A  1.1.1.1

After switching to

host.mydomain.de. CNAME newhost.mydomain.de, it stopped working.

Roman

[hshah]

Hi Roman,

Please give us output for "ping host host.mydomain.de". This will confirm potential DNS issue.

Regards,

Hardik Shah

[tshiv]

rkra

Can you make sure the FQDN refresh jobs are not failing. You can check them using the command:

> show jobs all

thanks

[hshah]

Hi Roman,

Sorry for type, provide us output for "ping host newhost.mydomain.de" and also "show jobs all"

Regards,

Hardik Shah

[rkra]

All FQDN Jobs are finished

Enqueued                     ID             Type    Status Result Completed

--------------------------------------------------------------------------

2014/10/15 12:21:38         894      FqdnRefresh       FIN     OK 12:21:42

2014/10/15 11:51:37         893      FqdnRefresh       FIN     OK 11:51:39

2014/10/15 11:21:36         892      FqdnRefresh       FIN     OK 11:21:38

2014/10/15 10:51:34         891      FqdnRefresh       FIN     OK 10:51:36

2014/10/15 10:21:33         890      FqdnRefresh       FIN     OK 10:21:35

2014/10/15 09:51:31         889      FqdnRefresh       FIN     OK 09:51:34

2014/10/15 09:21:30         888      FqdnRefresh       FIN     OK 09:21:32

2014/10/15 08:51:29         887      FqdnRefresh       FIN     OK 08:51:29

2014/10/15 08:21:28         886      FqdnRefresh       FIN     OK 08:21:30

2014/10/15 07:51:22         885      FqdnRefresh       FIN     OK 07:51:26

2014/10/15 07:21:20         884      FqdnRefresh       FIN     OK 07:21:24

2014/10/15 06:51:19         883      FqdnRefresh       FIN     OK 06:51:23

2014/10/15 06:21:18         882      FqdnRefresh       FIN     OK 06:21:20

2014/10/15 05:51:16         881      FqdnRefresh       FIN     OK 05:51:19

2014/10/15 05:21:15         880      FqdnRefresh       FIN     OK 05:21:17

2014/10/15 04:51:14         879      FqdnRefresh       FIN     OK 04:51:16

2014/10/15 04:21:12         878      FqdnRefresh       FIN     OK 04:21:16

2014/10/15 03:51:11         877      FqdnRefresh       FIN     OK 03:51:15

2014/10/15 03:21:10         876      FqdnRefresh       FIN     OK 03:21:14

2014/10/15 02:51:08         875      FqdnRefresh       FIN     OK 02:51:12

2014/10/15 02:21:07         874      FqdnRefresh       FIN     OK 02:21:11

2014/10/15 01:51:06         873      FqdnRefresh       FIN     OK 01:51:10

2014/10/15 01:21:04         872      FqdnRefresh       FIN     OK 01:21:09

2014/10/15 01:00:44         871          Content       FIN     OK 01:02:05

2014/10/15 01:00:17         870          Install       FIN     OK 01:00:44

2014/10/15 01:00:13         869           Downld       FIN     OK 01:00:15

2014/10/15 00:51:03         868      FqdnRefresh       FIN     OK 00:51:05

2014/10/15 00:21:02         867      FqdnRefresh       FIN     OK 00:21:06

2014/10/14 23:51:01         866      FqdnRefresh       FIN     OK 23:51:05

The real name is ZGTFS2.zgtroot.ads

Here the output

request system fqdn show

PROTEUS.intern.zgt.de  (Objectname PROTEUS.intern.zgt.de):

                    10.136.20.99              -919                      949

SFTP.ZGT.DE  (Objectname SFTP.ZGT.DE):

                   185.9.109.121              -949                      949

ZGTFS2.zgtroot.ads  (Objectname ZGTFS2.zgtroot.ads):

                    Not resolved

ZGTSQL1.zgtroot.ads  (Objectname ZGTSQL1.zgtroot.ads):

                    10.160.0.121               251                      949

ZGTSQL2.zgtroot.ads  (Objectname ZGTSQL2.zgtroot.ads):

                    10.160.0.122               251                      949

BUT!

PING from console ist WORKING when the FQDN is pointing to a CNAME too.

It seems FQDN Refresh and PING use differenet processes to resolve DNS names.

rkrakovic@PA1(active-secondary)> ping host ZGTFS2.zgtroot.ads

PING EFMETRO01A.intern.zgt.de (10.136.233.101) 56(84) bytes of data.

64 bytes from EFMETRO01A.intern.zgt.de (10.136.233.101): icmp_seq=1 ttl=251 time=0.464 ms

64 bytes from EFMETRO01A.intern.zgt.de (10.136.233.101): icmp_seq=2 ttl=251 time=0.462 ms

64 bytes from EFMETRO01A.intern.zgt.de (10.136.233.101): icmp_seq=3 ttl=251 time=0.449 ms

64 bytes from EFMETRO01A.intern.zgt.de (10.136.233.101): icmp_seq=4 ttl=251 time=0.450 ms

[hshah]

Hi Roman,

Actually Ping and FQDN both query DNS server for resolution. In my opinion they use the same DNS protocol.

To find out root cause follow bellow process.

1. tail follow yes mp.log ms.log

2. do commit

3. See if there is any FQDN related errors in ms.log.

Regards,

Hardik Shah

[rkra]

Hi,

tail follow yes mp.log ms.log = syntax error

rkrakovic@PA2(active-primary)> tail follow yes mp-log ms-log

/usr/bin/tail: cannot open `/var/log/pan/ms-log' for reading: No such file or directory

/usr/bin/tail: no files remaining

rkrakovic@PA2(active-primary)# commit

There are no changes to commit.

[edit]

[hshah]

Hi Roman,

Follow bellow step.

1. log session in text file

2. Run command "tail follow yes mp-log ms.log"

3. Open another teminal for firewall and do "commit Force"

Regards,

Hardik Shah