some questions about BIND 9's xfrin.c code...

[JINMEI Tatuya / 神明達哉]

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