Bug 784364 - Duplicate SOA record in bind zone transfer
Duplicate SOA record in bind zone transfer
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-24 12:34 EST by Martin Kosek
Modified: 2013-04-30 19:50 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-12 09:50:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Martin Kosek 2012-01-24 12:34:12 EST
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
Comment 1 Adam Tkac 2012-07-12 09:50:03 EDT
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.
Comment 2 Martin Kosek 2012-07-13 02:21:44 EDT
Sounds logical. Thanks for digging that out, Adam.

Note You need to log in before you can comment on or make changes to this bug.