Learn How We Can Help You Keep Teleworkers Protected During the COVID-19 Crisis

DNS DHCP IPAM

Reply
Highlighted
Accepted Solution

Issue data feed not updated when use fitur active trust ( Response Policy Zone )

Authority
Posts: 20
4136     0

Hi Guys,

 

I found problem in customer Infoblox for data feed not updated when use fitur active trust ( Responce Policy Zone ). We already check configuration from side Infoblox  for detail as below :

 

- We already configure license strings Response Policy Zone in Infoblox

- Our customer already confirmed Open IP Database Server WEST ( 54.69.93.185 ) & EAST ( 52.2.30.79 ) and also port 53 in firewall

- We got this IP Database Server WEST ( 54.69.93.185 ) & EAST ( 52.2.30.79 ) from website CSP ( https://csp.infoblox.com )

- We already PING from our Infoblox to IP 54.69.93.185 & 52.2.30.79 we got timeout

 

Infoblox > ping 54.69.93.185
pinging 54.69.93.185
^C
PING 54.69.93.185 (54.69.93.185) 56(84) bytes of data.
Infoblox >


Infoblox > ping 52.2.30.79
pinging 52.2.30.79
PING 52.2.30.79 (52.2.30.79) 56(84) bytes of data.

--- 52.2.30.79 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 14000ms

Infoblox > ping 54.69.93.185
pinging 54.69.93.185
PING 54.69.93.185 (54.69.93.185) 56(84) bytes of data.

--- 54.69.93.185 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 14004ms

Infoblox >

 

 

My question :

 

1. How to trace from side Infoblox to make sure IP 54.69.93.185 & 52.2.30.79 already open in firewall customer ?

2. Any check configuration from side Infoblox  to make sure our config Responce Policy Zone ( Active Trust ) already right ?

 

 

Thanks in advance,

 

Highlighted

Re: Issue data feed not updated when use fitur active trust ( Response Policy Zone )

Adviser
Posts: 128
4136     0

Hello Wibowo,

 

What specific feeds are you pulling from CSP (For RPZ) ? I did not quite understand what “fitur active trust” means. Let’s say, its “base.rpz.infoblox.local” as an example. Can you go to the syslogs of the secondary server configured for this RPZ feed & filter them for “Messages – contains - base.rpz.infoblox.local” (Replace the domain name as appropriate). See if you see anything specific like :

 

skipping zone transfer as master 54.69.93.185#53 (source 1.1.1.1#0) is unreachable

 

Or

 

zone base.rpz.infoblox.local/IN: Transfer started.

err transfer of 'base.rpz.infoblox.local/IN' from 54.69.93.185#53: failed to connect: timed out

info transfer of 'base.rpz.infoblox.local/IN' from 54.69.93.185#53: Transfer completed: 0 messages, 0 records, 0 bytes, 20.995 secs (0 bytes/sec)

 

Let’s forget about the fact that you are unable to ping it(That can be the case if ping is disabled on those IP addresses as well). Can you dig the primary servers(54.x.x.x) from the CLI of the configured secondary servers to see if there is a valid response ? You may do this just from the CLI of your Lead secondary if one is configured(If not all the secondaries for this specific RPZ zone). The dig should be performed in the following format :

 

dig @<54.69.93.185 or 52.2.30.79> <Complete_feedname> axfr -y HMAC-MD5:<key_name>:<key-data> axfr -b x.x.x.x

 

While “-b x.x.x.x” is optional. That’s just in case if you want to use a different interface other than LAN1. By default the query source would be LAN1. Technically, you need to use the interface address of the secondary server from which zone transfer is initiated(The private IP of the one that you’ve specified in CSP). An example of this query would be :

 

dig @54.69.93.185 base.rpz.infoblox.local -y portal.94.rta.ae-infoblox-1e2cemzz:isSaFp0NX5sjLYjtINxqAoIFvgDvefIrAt8Y+Jbu6aYCDuW9M1SXPt0pvPu5bgs3dDcELoC3eEEH0llO+a07KQ== axfr -b 1.1.1.1

 

While 1.1.1.1 is my LAN2 interface which I’ve chosen as the interface for zone transfer requests(Just per the example log mentioned above).

 

Please post any questions/results.

 

Best regards,

Mohammed Alman.

Highlighted

Re: Issue data feed not updated when use fitur active trust ( Response Policy Zone )

Authority
Posts: 20
4136     0

Hi Mohammed Alman,

 

 

Thanks for your response,

 

 

What specific feeds are you pulling from CSP (For RPZ) ?

 

Iam configure as below in side infoblox :

 

base.rpz.infoblox.local
antimalware.rpz.infoblox.local
ransomware.rpz.infoblox.local
bogon.rpz.infoblox.local
dhs-ais-ip.rpz.infoblox.local
dhs-ais-domain.rpz.infoblox.local

 

Below the sample dig from side Infoblox :

 

Infoblox > dig @52.2.30.79 base.rpz.infoblox.local axfr -y portal.694.exclusive-networks.com-infoblox-icnffz6n:2s53g8tgeFKYHuckdUsEyHwhpk10UkD/U481mOonHhSTD1RS3N8YXa7n51VEIXDYHUMv4pKaSnUKYCUfXkhh2w==

; <<>> DiG 9.10.2-ECS-M3 <<>> +noedns @52.2.30.79 -y portal.694.exclusive-networks.com-infoblox-icnffz6n base.rpz.infoblox.local axfr
; (1 server found)
;; global options: +cmd
base.rpz.infoblox.local. 604800 IN      SOA     ns1-rpz.csp.infoblox.com. support.infoblox.com. 1534423230 7200 3600 2592001 7200
base.rpz.infoblox.local. 604800 IN      NS      ns1-rpz.csp.infoblox.com.
base.rpz.infoblox.local. 604800 IN      NS      ns2-rpz.csp.infoblox.com.
actsten.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
*.actsten.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
ns1.actsten.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
ns2.actsten.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
ateheat.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
*.ateheat.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
ns1.ateheat.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
ns2.ateheat.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
commission-cooking.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
*.commission-cooking.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
deficit-litter.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
*.deficit-litter.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
description-pantyhose.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
*.description-pantyhose.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
goods-boot.accountant.base.rpz.infoblox.local. 14400 IN CNAME .

Enter <return> for next page or q<return> to cancel the command.

*.goods-boot.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
ranspot.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
*.ranspot.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
ns1.ranspot.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
ns2.ranspot.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
seekbar.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
*.seekbar.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
ns1.seekbar.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
ns2.seekbar.accountant.base.rpz.infoblox.local. 14400 IN CNAME .
aiddone.agency.base.rpz.infoblox.local. 14400 IN CNAME .
*.aiddone.agency.base.rpz.infoblox.local. 14400 IN CNAME .
artpays.agency.base.rpz.infoblox.local. 14400 IN CNAME .
*.artpays.agency.base.rpz.infoblox.local. 14400 IN CNAME .
asgame.agency.base.rpz.infoblox.local. 14400 IN CNAME .
*.asgame.agency.base.rpz.infoblox.local. 14400 IN CNAME .
assplit.agency.base.rpz.infoblox.local. 14400 IN CNAME .
*.assplit.agency.base.rpz.infoblox.local. 14400 IN CNAME .
bedneed.agency.base.rpz.infoblox.local. 14400 IN CNAME .
*.bedneed.agency.base.rpz.infoblox.local. 14400 IN CNAME .
besort.agency.base.rpz.infoblox.local. 14400 IN CNAME .
*.besort.agency.base.rpz.infoblox.local. 14400 IN CNAME .
bitswe.agency.base.rpz.infoblox.local. 14400 IN CNAME .

Enter <return> for next page or q<return> to cancel the command.
q
Infoblox >

 

Any advice again Mohammed Alman ?

 

 

Thank You,

 

 

Highlighted

Re: Issue data feed not updated when use fitur active trust ( Response Policy Zone )

[ Edited ]
Adviser
Posts: 128
4136     0

Hello There,

 

Thank you for this output. So that output looks good to me as long as LAN1 is used for zone transfer requests from this specific DNS server. How many name servers has been added as Grid secondaries for these RPZ feeds ? Any Lead secondary servers(Means, a single server in your grid entrusted to fetch the zone data from our feed server. All other grid members would get the feed data from this specific leader – Just edit the secondary name server for the RPZ feed & check whether any of them has the “Lead secondary” option enabled)  ? If not, did you check for the output from all the secondary DNS servers & confirm that the output looks like this (You don’t have to paste it here. Just see it for yourselves & post here if there is a problem. You just need to check the lead secondary if one is configured) ? Go for each feed name vs each DNS secondary server – just to be sure.

 

Next question : Did you check the syslogs of this specific secondary server(s) as what I’ve mentioned in my last comment to see what the transfer messages look like ? Can you post those logs here (You may remove customer specific data If any) ? That should give a reason for the transfer failure & we could explore more based on that.

 

Can you also confirm this :

 

  • When you go to Data Management -> Response Policy Zones -> “Last updated” has nothing ? -> Or when you “click” on the feeds, it says nothing..(It’ll automatically start downloading the CSV file with the feeds if updated. BEWARE: If transfers were completed, the CSV file exported would be huge & that process of exporting would add up to resource utilization)
  • RPZ licenses are valid on all the members configured as secondary server.
  • This is a new configuration & was never working.
  • How did you find that the transfer has failed ? (The results from the log that I’ve mentioned above is going to be critical here). If you referred to just the ping responses, i would request you to check those logs & confirm.

 

Let me know what you see/ think & we shall post our next comment accordingly.

 

Best regards,

Mohammed Alman.

 

Highlighted

Re: Issue data feed not updated when use fitur active trust ( Response Policy Zone )

Authority
Posts: 20
4137     0

Hi Mohammed Alman,

 

My Response Inline :

 

Can you also confirm this :

 

  • When you go to Data Management -> Response Policy Zones -> “Last updated” has nothing ? -> Or when you “click” on the feeds, it says nothing..(It’ll automatically start downloading the CSV file with the feeds if updated. BEWARE: If transfers were completed, the CSV file exported would be huge & that process of exporting would add up to resource utilization)

> I Have checked in configuration Infoblox  maximal Referesh every 2 hours and 1 hour for retry.

 

  • RPZ licenses are valid on all the members configured as secondary server

> Yes sir iam confirm for the licenses are valid because we got license strings from support infoblox. We have 4 Box Infoblox each 2 box ( DC ) & 2 box ( DRC ) we configured as HA ( Hight Availability )  so we have 4 license strings RPZ.

 

  • This is a new configuration & was never working.

> Previously working fine in 23 July 2018 and in this date we found issue license RPZ when the HA status : Active and have license RPZ working fine and if HA status : Active not have license RPZ can't working. We already escalated to support Infoblox and support infoblox sent again license strings to us so in date  16 August 2018 we inject the license. After we inject license we found data feed not updated. Right now we have 4 license strings RPZ

 

  • How did you find that the transfer has failed ? (The results from the log that I’ve mentioned above is going to be critical here). If you referred to just the ping responses, i would request you to check those logs & confirm

 > Maybe we inform to you monday 20 August 2018, because 17 August 2018 ( Independence Day Indonesia / Off day ) and 18 & 19 August 2018 (Saturday & Sunday / Off day ) & I don't have VPN access.

 

 

Highlighted

Re: Issue data feed not updated when use fitur active trust ( Response Policy Zone )

Authority
Posts: 20
4137     0

Hi Mohammed Alman & All,

 

We have 4 BOX for Infoblox & also we have 4 license RPZ we configure as below :

 

DC = BOX 1 ( New License ) & BOX 2 ( Old License ) setting as HA with IP VIP ( XX.XX.XX.XX )

DRC = BOX 1 ( Old Licese ) & BOX 2 ( New License ) setting as HA with IP VIP ( YY.YY.YY.YY  )

 

We have tested for domain with indication malicious domain ( ex : 61paris.fr ) the result is inkonsistent blocking. We expected for all BOX ( BOX 1 & BOX 2 )  should be blocking because we have 4 license RPZ. Whether this is behaviour for RPZ or something wrong problem ? Our customer expected should be blocking malicious domain for all BOX

 

 

Infoblox > dig @XX.XX.XX.XX 61paris.fr

; <<>> DiG 9.10.2-ECS-M3 <<>> +noedns @XX.XX.XX.XX 61paris.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38704
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;61paris.fr.                    IN      A

;; ANSWER SECTION:
61paris.fr.             86400   IN      A       213.186.33.107

;; Query time: 1268 msec
;; SERVER: XX.XX.XX.XX#53(XX.XX.XX.XX)
;; WHEN: Fri Aug 24 18:51:54 ICT 2018
;; MSG SIZE  rcvd: 44

Infoblox >

BOX2  DC ( Old License  ) successfull blocking

Infoblox > dig @XX.XX.XX.XX 61paris.fr

; <<>> DiG 9.10.2-ECS-M3 <<>> +noedns @XX.XX.XX.XX 61paris.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32303
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;61paris.fr.                    IN      A

;; ADDITIONAL SECTION:
base.rpz.infoblox.local. 7200   IN      SOA     ns1-rpz.csp.infoblox.com. support.infoblox.com. 1535107231 7200 3600 2592001 7200

;; Query time: 0 msec
;; SERVER: XX.XX.XX.XX#53(XX.XX.XX.XX)
;; WHEN: Fri Aug 24 18:54:43 ICT 2018
;; MSG SIZE  rcvd: 119

Infoblox >

BOX1 DRC ( Old License ) Failed for Blocking


Infoblox > dig @YY.YY.YY.YY 61paris.fr

; <<>> DiG 9.10.2-ECS-M3 <<>> +noedns @YY.YY.YY.YY 61paris.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43072
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;61paris.fr.                    IN      A

;; ANSWER SECTION:
61paris.fr.             86400   IN      A       213.186.33.107

;; Query time: 3088 msec
;; SERVER: YY.YY.YY.YY#53(YY.YY.YY.YY)
;; WHEN: Fri Aug 24 18:58:05 ICT 2018
;; MSG SIZE  rcvd: 44

Infoblox >

BOX2 DRC ( New  License ) Successfull Blocking

Infoblox > dig @YY.YY.YY.YY 61paris.fr

; <<>> DiG 9.10.2-ECS-M3 <<>> +noedns @YY.YY.YY.YY 61paris.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8390
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;61paris.fr.                    IN      A

;; ADDITIONAL SECTION:
base.rpz.infoblox.local. 7200   IN      SOA     ns1-rpz.csp.infoblox.com. support.infoblox.com. 1535109031 7200 3600 2592001 7200

;; Query time: 0 msec
;; SERVER: YY.YY.YY.YY#53(YY.YY.YY.YY)
;; WHEN: Fri Aug 24 19:03:03 ICT 2018
;; MSG SIZE  rcvd: 119

 

 

 

Thank You

Highlighted

Re: Issue data feed not updated when use fitur active trust ( Response Policy Zone )

Adviser
Posts: 128
4137     0

Hello Wibowo,

 

Thank you for those outputs. So these 4 boxes are configured as HA pairs (2 DNS serving nodes in total configured as RPZ secondaries). In an HA pair, both nodes share a single VIP address and a virtual MAC address so they can appear as a single entity on the network. While, all the core network services would be served by the VIP. I’m confused with the terminology, “Old license” & “new license” here. In either cases, aren’t they both valid RPZ licenses (Which are not expired)?If they aren’t expired, let’s address them as general RPZ license to avoid any confusion.

 

So let’s approach the problem in this way :

 

Case 1 : In case of HA pairs :

 

  • An example :
  1. DC BOX1(LAN1 - 1.1.1.1) & DC BOX2(LAN1 - 2.2.2.2) forms an HA pair with a VIP à 10.10.10.10. [DC-HA]
  2. DRC BOX1(LAN1 - 5.5.5.5) & DRC BOX2(LAN1 - 6.6.6.6) forms an HA pair with a VIP à 20.20.20.20. [DRC-HA] 

In my example above, you should expect RPZ blocking(Or any other core services like DHCP etc..) to be done only by 10.10.10.10 & 20.20.20.20. The individual LAN1 addresses would not do it.

 

  • Please check the DNS configuration file of each DC-HA & DRC-HA to see if there is an entry for “base.rpz.infoblox.local” as shown below :

 

     response-policy {

     zone "test" policy Given;# priority 1

     zone "base.rpz.infoblox.local" policy Nxdomain;# priority 2  -> [You may ignore the priority]. 

     zone "malware-dga.rpz.infoblox.local" policy Given;# priority 3

     zone "tor-exit-node-ip.rpz.infoblox.local" policy Given;# priority 4

     zone "ransomware.rpz.infoblox.local" policy Given;# priority 5

     } qname-wait-recurse no ;

 

  • If you see an entry as highlighted above & if a query pointing 10.10.10.10 or 20.20.20.20 is blocking the RPZ listed domains(base feed in this case), then this is “Working as expected”. You cannot expect 1.1.1.1 or 2.2.2.2 or 3.3.3.3 or 4.4.4.4 to block them.

 

Case 2 : If “BOX1 DC”, “BOX2 DC”, “BOX1 DRC” & “BOX2 DRC” are *standalone* DNS servers :

 

  • Please check the DNS configuration file of each “BOX1 DC” & “BOX1 DRC” to see if there is an entry for “base.rpz.infoblox.local” as shown in the config sample above.

 

  • If yes, my next approach would be to understand the DNS view in which you have configured the above response policy feeds(Could be identified from the DNS configuration file itself). Let’s say it is “default” DNS view.

 

  • Now, is this host machine from which you are querying “BOX1 DC”, “BOX2 DC”, “BOX1 DRC” & “BOX2 DRC” all falling into the same DNS view in which RPZ feed has been configured ? The view ordering can be different in different DNS servers. You just need to check for the view ordering in “BOX1 DC” & “BOX2 DRC” (Data management -> DNS -> Members -> Select “BOX1 DC” or “BOX2 DRC” -> Edit the DNS properties of that member -> Select “DNS views” -> See “Order of DNS Views” ). Per our example you need to ensure that all such queries fall into the ‘default’ DNS view where the base feed resides.

 

PS : I am confused with the fact that you’ve mentioned DC & DRC to be two HA pairs, while individual nodes in that cluster are responding to DNS requests(While it wouldn’t if it was an HA).

 

Best regards,

Mohammed Alman.

 

 

Highlighted

Re: Issue data feed not updated when use fitur active trust ( Response Policy Zone )

Authority
Posts: 20
4137     0

Hi Mohammed Alman,

 

Thanks for the explain to me. Btw, to show this output as below. Could you please share the command line ?

 

 

   response-policy {

     zone "test" policy Given;# priority 1

     zone "base.rpz.infoblox.local" policy Nxdomain;# priority 2  -> [You may ignore the priority]. 

     zone "malware-dga.rpz.infoblox.local" policy Given;# priority 3

     zone "tor-exit-node-ip.rpz.infoblox.local" policy Given;# priority 4

     zone "ransomware.rpz.infoblox.local" policy Given;# priority 5

     } qname-wait-recurse no ;

 

 

We will run if we onsite in customer.

 

 

Thank You,

Highlighted

Re: Issue data feed not updated when use fitur active trust ( Response Policy Zone )

Adviser
Posts: 128
4137     0

Hello,

 

Data management -> DNS -> Members -> Select the DNS server(Select either BOX1 DC or BOX1 DRC) -> From the toolbar, select "view" (DNS Configuration) -> Search for the keyword "response-policy ".

 

Best regards,

Mohammed Alman.

Highlighted

Re: Issue data feed not updated when use fitur active trust ( Response Policy Zone )

Authority
Posts: 20
4137     0
Hi Mohammed Alman, Thank you so much for guidence to me regarding this issue and i already explain to customer regarding behavior RPZ and they accepted my explanation. Regards, -bowo-
Showing results for 
Search instead for 
Do you mean 

Recommended for You