[Yeti DNS Discuss] 答复: An IXFR Fallback to AXFR Case

Davey Song(宋林健) ljsong at biigroup.cn
Mon May 16 02:53:38 UTC 2016


>i believe that a simple change to the IXFR rules would account for MZSK,
and that's to prefer as an IXFR source the particular zone master server who
most recently supplied an IXFR or AXFR.

That is exactly Stephane's suggestion to tie each slave root server to a
specific DM.

>we can't cope with load balancers that represent multiple zone masters,
since they will share an IP address.
agree.

>but for MZSK, the zone slave (Yeti public server) it will know the address
of several zone masters (Yeti hidden server), and it should only encounter
DNSSEC metadata incoherence if it changes from one hidden master to another
on successive AXFR-or-IXFR then IXFR operations.

>in addition, a recommendation could be added in an RFC1995-bis document
stating that in the event of an IXFR incoherence error (zone difference
refers to records not in evidence), an IXFR client should fall back to AXFR
automatically.

It is stated in RFC5936 that the client can stop adding/deleting when it
encounters IXFR incoherence error.

" For example, a client may retrieve a zone by AXFR from one server,
   and then apply an incremental change obtained by IXFR from a
   different server.  If the two servers have different ideas of the
   zone contents, the client can end up attempting to incrementally add
   records that already exist or to delete records that do not exist. "
--- RFC5936

It is ambiguous that this statement is not clearly asking to stop doing IXFR
and fall back to AXFR. For example, Knot merges the two zones and ignore the
difference (stop adding and deleting, but continue IXFR); And NSD does what
we expected and proposed (stop IXFR and fall back to AXFR).

>vixie





More information about the discuss mailing list