Inconsistent XFR behavior with builtin empty zones
Summary
Using database "_builtin empty ...;
results in inconstant behavior between AXFR and IXFR. Additionally, the IXFR results with dig are inconsistent with standard transfers. (These are very minor issues, and perhaps more interesting than anything else.)
Related issue: _builtin empty
is not documented in the ARM.
BIND version used
9.14.3. The issue was also seen in a 9.12.X version.
Steps to reproduce
Entire named.conf:
options { directory "/etc/namedb"; };
zone "cnn.com" { type master; database "_builtin empty x.invalid. TedTurner"; };
Checking the SOA and NS RRs gets non-problematic results.
dig +noall +answer @127.1 soa cnn.com
cnn.com. 86400 IN SOA x.invalid. TedTurner.cnn.com. 0 28800 7200 604800 86400
dig +noall +answer @127.1 ns cnn.com
cnn.com. 0 IN NS x.invalid.
AXFR is denied, which is just fine.
dig +noall +answer @127.1 axfr cnn.com
; Transfer failed.
IXFR is not denied, an inconsistency. Furthermore, the response contains the SOA, but not the NS record. Finally, the SOA comes only once, not both before and after all the other RRs as is standard.
dig @127.1 ixfr=1 cnn.com
; <<>> DiG 9.14.3 <<>> @127.1 ixfr=1 cnn.com
; (1 server found)
;; global options: +cmd
cnn.com. 86400 IN SOA x.invalid. TedTurner.cnn.com. 0 28800 7200 604800 86400
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 09 16:48:27 CEST 2019
;; XFR size: 1 records (messages 1, bytes 119)
What is the current bug behavior?
Shown above.
What is the expected correct behavior?
The easiest solution would be for IXFR to result in a failed transfer like AXFR.
A short blurb in the ARM about the using the _builtin empty would be a good idea.
Relevant configuration files
Shown above.