Subject: Re: [dnsext] draft-ah-dnsext-rfc1995bis-ixfr-03

From: Masataka Ohta <[email-masked]>
Date: Thu, 05 Apr 2012 17:56:48 +0900

Though appendix A has some abstract statements, I still can't
see any realistic operational reason to have IXFR-ONLY.

For operational examples discussed in ML, it is merely
necessary, in section 6.3, to state optional condensation
is "NOT RECOMMENDED".

						Masataka Ohta
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 18 Apr 2012 21:00:19 +0200 (MESZ)

Lubos,
thanks for your quick review of draft-ietf-dnsext-rfc1995bis-ixfr-00,
which has been forwarded to the mailing list by Ondrej Sury
on 29 Mar 2012, 17:50:52 +0200 (message archived at
  http://www.ietf.org/mail-archive/web/dnsext/current/msg12399.html ).

Inline below I note the actions taken so far on your suggestions,
in my working copy of the draft.  The next draft revision is planned
to be submitted within a week from now.

> Hi,
>
> I got our head engineer of Knot DNS (Lubos Slovak he's in Cc:), who also
> implementor IXFR (from scratch) to review the document and here's the
> result (copying verbatim, just added references to sections and 'nit'
> words):
>
> 1) section 1.4 - nit: "makes freely use" -> s/freely/free

It actually was intended to say: "freely makes use of ...",
and that's what the draft now says.

>
> 2) Section 2, page 8 - nit: "Therefore, is becomes apparent" -> s/is/it

Fixed.

>
> 3) Section 2, last paragraph - why has to RRSIG(SOA) [to] follow
>    the SOA in the AXFR-fallback example?

Actually, there's no "MUST" requirement, but it is good practice
in AXFR implementations to group RRsets together in AXFR responses,
and, according to the base DNSSEC specs, the RRSIG(SOA) conceptionally
is part of the SOA RRset (except in the context of a query for RRSIG,
which does not apply here).  However, server implementations have
found it convenient to send RRsets as contiguous groups within AXFR
responses (because of the manner they are stored, for grouped
inclusion in ordinary DNS responses); similarly, for clients that
choose to perform detailed plausibility checks of received zone
content before serving a new version of the zone data, checking of
consistency likely will comprise a check for equality of TTL values
within RRsets (Section 5.2 of RFC 2181), and maybe even RRSIG
verification, it is beneficial to receive the RRs of RRsets grouped
together (so that common DRAM cache replacement algorithms make it
much more likely to find the related RRs in the most high-speed
memeory comonents present in the system, and hence processing will
be much faster).  Since IXFR is all about speed and optimization
of the zone synchronization process, such server behavior is very
desirable in IXFR implementations as well.

Taking this into account, I have tentatively modified the draft
text to now say:

  "In contrast, in the case of fallback to AXFR, the IXFR response
   would typically convey, in order:"
        ^^^^^^^^^^^

But if implementers do strongly prefer to have IXFR clients find
RRsets grouped together, or at leaest to have the RRSIG(SOA) RRs
always be placed at the beginning (in the case of IXFR fallback
to AXFR), we could make the RR order shown in the draft mandatory
(SHOULD or MUST) for IXFR servers.

Opinions from other implementers?

>
> 4) Section 6.2 - missing RFC2119 language; shoulds and mays are small
>    caps, is that intentional?

The server's purging behavior is difficult to test externally.
It is strongly recommended to use RFC 2119 terms sparingly and
only in cases where the behavior is needed for interoperability
and can be tested by observing externally visible behavior.

The mandatory rules on "fallback to AXFR" IMO are sufficient to
ensure interoperability, and IXFR-ONLY is dedicated to address
efficiency issues that plague deployments in specific circumstances,
so the details of IXFR server purging behavior seem to be local to
implementations, subject to implementation-specific resource
management strategies and resource restrictions, and hence out of
the bailiwick of RFC 2119.  ( :-) )

However, if the WG feels strong about having more detailed, yet
testable, requirements regarding the purging and condensation
strategy of IXFR servers (Sections 6.2 and 6.3 of the I-D),
the draft of course can be modified accordingly.

>
> 5) And today new question have arrised:
>    "What should IXFR client do if it receives incomplete
>    multichunked IXFR response?"
>    A) discard whole transfer and start over;
>    B) save usable chunks (e.g. use data to update zone from sn_o to
>       sn_o+x, where sn_o+x < sn_n)

Section 7.1 already is explicit in saying that an IXFR client "MAY"
follow strategy B).  In particular, the draft says:

|7.  Client Behavior
|
|  [...]
|
|7.1.  Zone Integrity
|
|  The elaborations on Zone Integrity for AXFR in Section 6 of RFC 5936
|  [RFC5936] apply in a similar fashion for IXFR.
|
|  However, during the receipt of an incremental IXFR response, and upon
|  successful processing of an SOA RR that serves as a sentinel for the
|  end of any change information chunk, an IXFR client MAY immediately
|  apply and commit to stable storage the SOA serial number change
|  described by that chunk (and previous chunks, if not already done).
|  This operation MUST externally appear as an atomar operation.
|
|  [...]

Please revisit the full text in Section 7.1 for the detailed
considerations and tell us whether that is sufficient.

>
> Ondrej on behalf of Lubos
>
> P.S.: Our Knot DNS team (different people than one of the authors of
>       this document) will do a full review in WGLC.

Thanks in advance!

I hope that the chairs will proceed to issue WGLC on the upcoming
next draft version; experience has show that this is a strong
incentive for the WG to take a closer look at the document and
commenting on it.

> ...
> <snip>  {original draft announcement}  </snip>

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 19 Apr 2012 09:53:59 +0200

On 04/18/2012 09:00 PM, Alfred � wrote:
...
> Actually, there's no "MUST" requirement, but it is good practice in
> AXFR implementations to group RRsets together in AXFR responses, 
> and, according to the base DNSSEC specs, the RRSIG(SOA)
> conceptionally is part of the SOA RRset (except in the context of a
> query for RRSIG, which does not apply here).  However, server
> implementations have found it convenient to send RRsets as
> contiguous groups within AXFR responses (because of the manner they
> are stored, for grouped inclusion in ordinary DNS responses);
> similarly, for clients that choose to perform detailed plausibility
> checks of received zone content before serving a new version of the
> zone data, checking of consistency likely will comprise a check for
> equality of TTL values within RRsets (Section 5.2 of RFC 2181), and
> maybe even RRSIG verification, it is beneficial to receive the RRs
> of RRsets grouped together (so that common DRAM cache replacement
> algorithms make it much more likely to find the related RRs in the
> most high-speed memeory comonents present in the system, and hence
> processing will be much faster).  Since IXFR is all about speed and
> optimization of the zone synchronization process, such server
> behavior is very desirable in IXFR implementations as well.
> 
> would typically convey, in order:" ^^^^^^^^^^^
> 
> always be placed at the beginning (in the case of IXFR fallback to
> AXFR), we could make the RR order shown in the draft mandatory 

OpenDNSSEC 1.4.0a1 does indeed now transfer the zone in the order such
that signatures follow the corresponding RRsets immediately. However,
due to a change in the way we store the data in the backup files, that
might change into first send all the RRsets, followed by all NSEC(3)s
and finally all RRSIGs, because that's the order they are stored.

You argue that this is disadvantageous for the IXFR client, but that
is depending on the implementation I guess. In our case, it would be
beneficial for the IXFR server to do otherwise. So at least, I would
disagree with making the RR order more mandatory.

Best regards,
  Matthijs

>> 4) Section 6.2 - missing RFC2119 language; shoulds and mays are
>> small caps, is that intentional?
> 
> The server's purging behavior is difficult to test externally. It
> is strongly recommended to use RFC 2119 terms sparingly and only in
> cases where the behavior is needed for interoperability and can be
> tested by observing externally visible behavior.
> 
> efficiency issues that plague deployments in specific
> circumstances, so the details of IXFR server purging behavior seem
> to be local to implementations, subject to implementation-specific
> resource management strategies and resource restrictions, and hence
> out of the bailiwick of RFC 2119.  ( :-) )
> 
> strategy of IXFR servers (Sections 6.2 and 6.3 of the I-D), the
> draft of course can be modified accordingly.
> 
> 
>> 
>> 5) And today new question have arrised: "What should IXFR client
>> do if it receives incomplete multichunked IXFR response?" A)
>> discard whole transfer and start over; B) save usable chunks
>> (e.g. use data to update zone from sn_o to sn_o+x, where sn_o+x <
>> sn_n)
> 
> Section 7.1 already is explicit in saying that an IXFR client
> "MAY" follow strategy B).  In particular, the draft says:
> 
> |7.  Client Behavior | |  [...] | |7.1.  Zone Integrity | |  The
> elaborations on Zone Integrity for AXFR in Section 6 of RFC 5936 |
> [RFC5936] apply in a similar fashion for IXFR. | |  However, during
> the receipt of an incremental IXFR response, and upon |  successful
> processing of an SOA RR that serves as a sentinel for the |  end of
> any change information chunk, an IXFR client MAY immediately |
> apply and commit to stable storage the SOA serial number change |
> described by that chunk (and previous chunks, if not already
> done). |  This operation MUST externally appear as an atomar
> operation. | |  [...]
> 
>> P.S.: Our Knot DNS team (different people than one of the authors
>> of this document) will do a full review in WGLC.
> 
> Thanks in advance!
> 
>> ... <snip>  {original draft announcement}  </snip>
> 
> 
> Kind regards, Alfred.
>