DNS Express Off-Box IXFR Takes About 20 Seconds

is there any error message in the /var/log ?
ihealth may provide some analysis too

Hi HosseinAmery,

Frequent DNS Express zone transfers prevent updated zone data from becoming available.

DNS Express performs a zone transfer more frequently than every 15 seconds.

Have you tried using dnsxdump in BASH mode

The dnsxdumputility displays the DNS Express database information.

The dnsxdump utility outputs directly to the console. If you have a large number of zones, or zone resource records, you can redirect the output to a text file for later review in your preferred text editor.

For example, to redirect the output to /var/tmp/my_zones.txt you would type the following command:

dnsxdump > /var/tmp/my_zones.txt

To see or troubleshoot zone transfers, we can refer to the /var/log/ltm log file. A quick examination of the log should show a successful zone transfer in the lab:

#tail -100 /var/log/ltm | grep zxfrd

Can you also check

dnsexpress.notifyport <value>

dnsexpress.xfrnotifydelay <value>

default value is 5 seconds

root@(F5-Design_Engg02)(cfg-sync Standalone)(Active)(/Common)(tmos)# list sys db dnsexpress.xfrnotifydelay
sys db dnsexpress.xfrnotifydelay {
value "5"
}

This DB variable controls the delay in seconds between the time the zxfrd process receives a DNS Notify message from the authoritative DNS server and the time it schedules an AXFR/IXFR.
Note: This does not mean the zone transfer occurs immediately after this delay as the start of the zone transfer also depends on the load on the BIG-IP system, the authoritative DNS server and the network between them; as well as the size of the zone transfer.

The zxfrd process manages zone transfers and writes to the zone database files. When it receives an update request, it initiates a zone transfer to the authoritative DNS server. The results of the zone transfer are then committed to the zone DB.
The zxfrd process may restart and produce a core file if:
An active zone transfer is interrupted
The interruption is between the BIG-IP system and the DNS server
The interruption is caused by a network outage
The zxfrd process may also produce a core file and restart when:
Importing a zone file that contains a WINS RR

The zxfrd process manages zone transfers and writes to the zone database files.
zxfrd listens on ::1:5353
Zone transfer uses tcp:53

search for

tailf /var/log/gtm | grep zxfrd
tmsh show ltm dns dns-express

If DNS Express not initiating Zone Transfer after receiving DNS Notify Please Verify Notify TSIG option is enabled (by default) in the DNS Express zone and waits for the TSIG key (transaction signature) to be sent from the Authoritative DNS Server

Else
Disable the Verify Notify TSIG option on the DNS zone. With this configuration, DNS Express can process a NOTIFY message without a TSIG key, even when a subsequent zone transfer requires a TSIG key.

https://my.f5.com/manage/s/article/K15468995

K45411181: Configuring DNS Express using tmsh

https://my.f5.com/manage/s/article/K45411181

Hope this Helps

🙏

 

 

Hi  HosseinAmery , 

I havn't measure the time exactily for the IXFR but I noticed yes it took some time to replicate the changes in Bind to bigip DNS express zones. 

But I will recommend somthing else. 

Make sure that you added this also-notify statement in the BIND (master) configuration file beside allow-transfer statement as well. 

here this BIND standard configuration statements : https://www.zytrax.com/books/dns/ch7/xfer.html#also-notify

have a look on : 

1. allow-notify
2. allow-transfer
3. allow-update
4. also-notify
5. notify

   Try and check those and measure the delta time for the IXFR to be done. 
   
   use dnsxdump on bash to see the changes or you can take a pcap to capture those changes and see the negotiation between bigip and BIND because the incremental zone transfer depends on changes in SOA records between off-BOX BIND and bigip and what the time needed for these negotiations after the change of SOA record value to re-calculate the Delta for these changes on zones and create the IXFR to update BIGIP. 
   
   So somehow I see this process still need sometime , the most important thing is how to configure your BIND correctly to follow the standard way for Zones transfer. 
   
   Note:
   Be careful when using dnsxdump command , because if you have much zones and records your bigip may crash. 
   I see using tcpdump to capture it and see the IXFR and it's relivant negotiations for zone transfers will give you the optimal visibility and how to calculate the time difference and delay.
   
   Hope this helps you.