Subject: more RFC1995 implementors feedback

From: Josh Littlefield <[email-masked]>
Date: Tue, 23 Nov 1999 20:03:29 -0500

I think Andreas' clarifications are all excellent (modulo my prior
comments).  Having implemented IXFR nearly 2 years ago and not submitted RFC
feedback, I've lost some of the issues which I encountered with the spec,
but in reviewing mail I exchanged with Masataka Ohta at the time, I think
Andreas' addressed most of them.  I would make one addition.

I think something should be included, probably in section 4, describing the
interpretation of "misleading" data.  That is, deletions of non-existent
records, and addition of duplicate or conflicting records.  These are real
issues which arise from buggy implementations, and I think we should
recommend the action to be taken.

I would suggest adding the following after paragraph 4 of section 4 (the
para. which begins, "Modification of an RR is..."

   A difference sequence which indicates the removal of a non-existent
   RR, or the addition of a duplicate or conflicting RR, should be
   considered an indication that the IXFR client is out-of-sync with the
   IXFR server.  The IXFR SHOULD be aborted, and an AXFR requested from
   the same server.

We could cite RFC 2136 (Sec. 3.4.2.2) for the definition of RR conflicts,
since it is not succinctly described elsewhere that I know of, but the
language there also contains UPDATE-specific language about SOA records.

-- 
========================================================================
Josh Littlefield                                     Cisco Systems, Inc.
[email-masked]                                         250 Apollo Drive
tel: 978-244-8378  fax: 978-244-8378          Chelmsford, MA  01824-3627

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Nov 99 14:51:35 JST

Josh;

>    IXFR server.  The IXFR SHOULD be aborted, and an AXFR requested from

For deletion of non-existent RR, that could be a good strategy.

But, for conflicting RRs, it's an implementation detail. Or, what if
there are conflicting RRs in AXFR?

Note that it is *VERY* difficult to say something conflicting, because, for
example, secure DNS node MUST have CNAME and other RRs. On the other
hand, secure DNS referral does NOT have to have NS and other non-A RRs
that there is unnecessary complication in secure DNS for the referral.

So, the safe strategy is to accept anything in a zone file or zone transfer
though some warning message could help.

Finally, there actually can be duplicate TXT RRs today. There will
be other RRs or new use of existing RRs with possible duplication
in the future. So, never mind that something may be duplicated.

							Masataka Ohta