dns.query.inbound_xfr with incremental zone transfer

[nguyenhoanganhtu2406]

Hi,

I am trying to perform a zone transfer using dns.query.inbound_xfr, because the dns.query.xfr has been deprecated (love how easy it is to use this for zone transfer), and I took a look at discussion #707 already. But it still seems odd to me when I am trying to perform an incremental zone transfer. An exception was raised like the following:

 File "dns_action.py", line 72, in do_inbound_xfr
   query.inbound_xfr(dns_server_ip, dnszone, zone_transfer_query)
 File "/usr/local/lib/python3.8/dist-packages/dns/query.py", line 1143, in inbound_xfr
   done = inbound.process_message(r)
 File "/usr/local/lib/python3.8/dist-packages/dns/xfr.py", line 218, in process_message
   self.txn.delete_exact(name, rdataset)
 File "/usr/local/lib/python3.8/dist-packages/dns/transaction.py", line 211, in delete_exact
   return self._delete(True, args)
 File "/usr/local/lib/python3.8/dist-packages/dns/transaction.py", line 466, in _delete
   raise DeleteNotExact(f'{method}: missing rdataset')
dns.transaction.DeleteNotExact: delete_exact(): missing rdataset

The packets were captured successfully and the answer section was somewhat identical to the following:

@ 3600 IN SOA tvdns testg.example.com. 682943594 1200 180 1209600 3600
@ 3600 IN SOA tvdns testg.example.com. 682943591 1200 180 1209600 3600
testg-issue 3600 IN A 192.168.6.110
@ 3600 IN SOA tvdns testg.example.com. 682943592 1200 180 1209600 3600
testg-issue 3600 IN A 192.168.6.111
@ 3600 IN SOA tvdns testg.example.com. 682943592 1200 180 1209600 3600
@ 3600 IN SOA tvdns testg.example.com. 682943593 1200 180 1209600 3600
testxfer 3600 IN A 192.168.6.115
@ 3600 IN SOA tvdns testg.example.com. 682943593 1200 180 1209600 3600
testxfer 3600 IN A 192.168.6.115
@ 3600 IN SOA tvdns testg.example.com. 682943594 1200 180 1209600 3600
@ 3600 IN SOA tvdns testg.example.com. 682943594 1200 180 1209600 3600

The code that was used to perform the incremental zone transfer is the following:

dnszone = zone.Zone(zone_name)
zone_transfer_query, *_ = xfr.make_query(
    dnszone,
    serial=serial,
    keyring=tsigkeyring.from_text(key_dict),
    keyalgorithm=key_alg,
)
query.inbound_xfr(dns_server_ip, dnszone, zone_transfer_query)
print(dnszone.nodes.keys())

It seems that the process_message, which is called in the inbound_xfr method, processed the RR sets wrongly from the answer. Or am I doing something incorrectly? Any help would be appreciated.

Thanks.

[rthalley]

The error message means "the IXFR data told us we need to delete some specific rdata, but we couldn't find an rdataset with that name and type". In your case it probably means that your input zone did not have a testg-issue rdataset. If I try your IXFR with a zone which has an initial rdataset for testg-issue consisting of "testg-issue 3600 IN A 192.168.6.110" then everything works. If I delete this line, then I get the same error you do. Dnspython has to raise an error here as any deviation of the zone content from what the IXFR is asking for means you are out-of-sync with the primary (you should fall back to AXFR in that case).

[nguyenhoanganhtu2406]

Then why does the old query.xfr work? For example if I already have a SOA serial, all I want is to retrieve the difference sequences happening between the older SOA serial and the latest one. If I have to do the same as you did here, by providing the zone content initially to match and perform on the query's response, I will have to load the whole current zone data to my program, that will hurt the performance.

If the error was not raised, and the behavior was the same as the old xfr one, I could delete and add the RR sets simply. Could I do something else so that the new inbound_xfr works the same as the old xfr one?

[rthalley]

dns.query.xfr() just returns a sequence of messages; if you want to process the IXFR messages yourself, you can continue using dns.query.xfr(). It's deprecated for actually updating zones, but I'm not going to remove it.

[nguyenhoanganhtu2406]

Thank you for your quick and comprehensive response.