[bind10-dev] initial ideas on the "difference" design

Kevin Tes xiejiagui at cnnic.cn
Thu Oct 13 05:35:45 UTC 2011


To support IXFR-out, we should consider IXFR-in too. I think these
two have the same needs.

For 'masters' Synchronizes data with 'slaves' or 'slaves' ask for
synchronizing data, as those happen, bind needs the diffs data.

Example:
begins of the zones:

test  soa 1

        example.test      ns  ns1.example.test
        b.test            a   1.1.1.1
        ns1.example.test  a   1.1.1.2
=======================================================================

for update a zone:

nsupdate : remove  example.test  ns  ns1.example.test
           remove  ns1.example.test  a   1.1.1.2

           add     example.test  ns  ns2.example.test
           add     ns2.example.test  A  1.1.1.3

                                                        // soa + 1
----------------------------------------------------------------------     
or         add     example.test  ns  ns3.example.test
           add     ns2.example.test  A  1.1.1.5
                                                        // soa + 1
-----------------------------------------------------------------------
or         remove  b.test    a   1.1.1.1
           add     b.test    a   1.1.1.4

           remove  b.test    a   1.1.1.4
           add     b.test    a   1.1.1.1  
                                                        // soa + 1
-----------------------------------------------------------------------

now the zone is 

test  soa 4

example.test   ns  ns2.example.test
               ns  ns3.example.test

b.test            a   1.1.1.1
ns2.example.test  a   1.1.1.3
ns2.example.test  a   1.1.1.5


we just need to store the data each time user has changed the zone in
order

so when synchronizing the data, slaves just needs to traversal the
changed data for soa 1 to soa 4.


we store all these data in zone_log table:
ID   
zone_id 
soa 
operation_type  
name	
data_type(or rr_type)
data

example:
for add a ns RR:  add     example.test  ns  ns3.example.test
1, 			--id
2, 			--zone_id
2, 			--soa
'a',			--operation_type: 'a':add,'d':delete
'example.test', 	--name
'ns',			--data_type or rr type
'ns3.example.test' 	--rr data


after each synchronized, empty this table.

=======================================================================
Should we consider when delete a zone, how the slaves synchronizes with 
the masters??
=======================================================================







More information about the bind10-dev mailing list