Q. IXFR client behavior
Mark Andrews
Mark_Andrews at isc.org
Thu Jan 12 09:31:19 UTC 2006
> 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
More information about the bind-users
mailing list