Q. IXFR client behavior

[Mark Andrews]

> Hi,
> 
> Now I'm trying to test Increment Zone Transfer (IXFR) using bind 9.3.2
> as following enviroment. And I have a question about IXFR mechanizm on BIND9.
> 
> Q1. Why does an IXFR client make an IXFR query using TCP rather than UDP at f
> irst?

	Because it is easier to do it this way.  There is no
	requirement to initiate IXFR over UDP.  We also don't support
	sending responding to IXFR over UDP except to send back the
	SOA record which the client interprets as "up-to-date" or
	"use-tcp" depending apon the serial value.
 
> Q2. Why does an IXFR client ignore query response's SOA REFRESH time?
>     An IXFR server set 180sec as REFRESH time, but an IXFR client sends query
>     QTYPE=SOA every aroud 300sec.
>     (I put capture file at http://www.tahi.org/~ozoe/dns/ixfr_inclement.pcap)

	Look at min-refresh and min-retry.   These are sanity checks to
	ensure a ISP can't be swamped by clients setting these values to
	too small values.  Similarly max-refresh and max-retry ensures
	a slave will make periodic queries with a reasonable frequency
	even is there are riduculous values in the SOA record.
 

> Network
> -------
> 
>      IXFR client
>         |192.168.0.10
> --+-----+-----
>   |
>  IXFR server
>    192.168.0.30
> 
> named.conf on IXFR server
> -------------------
> options {
>         directory "/etc/namedb";
>         provide-ixfr yes;
>         ixfr-from-differences yes;
>         notify no;
>         dump-file "s/named_dump.db";
> };
> 
> zone "sec.example.com" {
>         type master;
>         file "sec.example.com";
> };
> 
> 
> named.conf on IXFR client
> --------------------------
> options {
>         directory "/etc/namedb";
>         request-ixfr yes;
>         notify no;
>         dump-file "s/named_dump.db";
> };
> 
> zone "sec.example.com" {
>         type slave;
>         masters {192.168.0.30;};
>         file "s/sec.example.com";
> };
> 
> 
> sec.example.com zone file on IXFR server
> -----------------------------------------
> 
> $TTL    86400; TTL of 30 sec
> @       IN      SOA     NS7.sec.example.com. root.sec.example.com.  (
>         1       ; Serial
>         180     ; Refresh
>         30      ; Retry
>         360     ; Expire
>         30      ; Minimum
> )
>         IN      NS      NS7.sec.example.com.
>         IN      NS      NS1.sec.example.com.
>         IN      MX      10      NS7
> NS7     IN      A       192.168.0.31
>         IN      AAAA    3ffe:501:ffff:100::31
> NS1     IN      A       192.168.0.10
>         IN      AAAA    3ffe:501:ffff:100::10
> CL1     IN      A       192.168.0.20
> CL2     IN      A       192.168.0.21
> 
> Updated zone information file on IXFR server
> --------------------------------------------
> 
> $TTL    86400; TTL of 30 sec
> @       IN      SOA     NS7.sec.example.com. root.sec.example.com.  (
>         2       ; Serial
>         180     ; Refresh
>         30      ; Retry
>         360     ; Expire
>         30      ; Minimum
> )
>         IN      NS      NS7.sec.example.com.
>         IN      NS      NS1.sec.example.com.
>         IN      MX      10      NS7
> NS7     IN      A       192.168.0.31
>         IN      AAAA    3ffe:501:ffff:100::31
> NS1     IN      A       192.168.0.10
>         IN      AAAA    3ffe:501:ffff:100::10
> CL1     IN      A       192.168.0.21
> CL3     IN      A       192.168.0.22
> 
> -- 
> Nobumichi Ozoe
> IPv6 Business
> Network & Software Development Dept.
> Yokogawa Electric Corporation
> E-mail: Nobumichi.Ozoe at jp.yokogawa.com
> URL: http://www.yokogawa.com/
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org