Description of problem: Zone transfer from bind contains 2 SOA records: # dig example.com axfr ; <<>> DiG 9.8.1-P1-RedHat-9.8.1-4.P1.fc16 <<>> example.com axfr ;; global options: +cmd example.com. 86400 IN SOA ns.example.com. hostmaster.example.com. 2012200101 3600 900 1209600 3600 example.com. 86400 IN NS ns.example.com. server.example.com. 86400 IN AAAA 2001::beef:1 server.example.com. 86400 IN A 192.168.0.1 example.com. 86400 IN SOA ns.example.com. hostmaster.example.com. 2012200101 3600 900 1209600 3600 ;; Query time: 40 msec ;; SERVER: 10.16.78.68#53(10.16.78.68) ;; WHEN: Tue Jan 24 12:29:39 2012 ;; XFR size: 5 records (messages 1, bytes 203) The zone transfer should contain just one SOA record. Version-Release number of selected component (if applicable): bind-9.8.1-4.P1.fc16.x86_64 bind-utils-9.8.1-4.P1.fc16.x86_64 How reproducible: Steps to Reproduce: 1. Just run "dig example.com axfr" against a configured bind zone with zone transfers allowed Actual results: 2 duplicate SOA records are returned. Expected results: Just one SOA record is returned
After further inspection this is intentional behavior per RFC 5936: ... 2.2. AXFR Response ... An AXFR response that is transferring the zone's contents will consist of a series (which could be a series of length 1) of DNS messages. In such a series, the first message MUST begin with the SOA resource record of the zone, and the last message MUST conclude with the same SOA resource record. Intermediate messages MUST NOT contain the SOA resource record. ... So every transfer must start and end with the same SOA. Closing as notabug.
Sounds logical. Thanks for digging that out, Adam.