I've been looking at BIND 9's IXFR(-in) implementation and encountered
a few questions. I was not sure if these should be considered a bug,
so I'm asking these here before actually filing a bug report.
The source file in question is lib/dns/xfrin.c.
1. In xfrin_recv_done(), if an RR is found in the state of
XFRST_IXFR_END, it will be treated as an error of DNS_R_EXTRADATA
and xfrin will fail. But all diffs have been committed to the DB
by then (and will be visible to clients if the server is multi
threaded, even if the intermediate changes may become invisible
once the error is detected). Is that intentional and okay?
2. Likewise, if an IXFR response consists of multiple difference
sequences (i.e. multiple SOA changes), each change sequence is
committed to the DB at the end of the sequence (and will be visible
to clients). If an error is detected in a later difference
sequence, the xfrin process is aborted at that point, but some part
of the changes have already been visible to clients. Is that
intentional and okay?
I guess both these questions are related to this part of RFC1995:
An IXFR client, should only replace an older version with a newer
version after all the differences have been successfully processed.
(section 4)
It's not clear to me whether "all the differences" mean all the
differences of all the sequences or all differences of each sequence.
If it's the former, the BIND 9's behavior seems to break this
specification; if it's the latter, it performs exactly what's
specified.
3. When adding an RR in IXFR, an NS record with a wildcard owner name
is rejected:
case XFRST_IXFR_ADD:
...
if (rdata->type == dns_rdatatype_ns &&
dns_name_iswildcard(name))
FAIL(DNS_R_INVALIDNS);
This is probably a good practice, but when does it specifically
check this case, and this case only? For example,
rbtdb.c:loading_addrdataset() also rejects wildcard NSEC3 or
non-origin SOA. Why shouldn't xfrin also reject them? I guess we
could either be very strict or generally accept what the primary
gives, but the current behavior seems to be incomplete.
---
JINMEI, Tatuya
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
