Re: [dnsext] Review of draft-ietf-dnsext-rfc1995bis-ixfr-00.txt (from Knot DNS team)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/18/2012 09:00 PM, Alfred � wrote:
...
>> 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?

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.
> 
> 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.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPj8SWAAoJEA8yVCPsQCW5LYoIAK4OhT010si9+fBGzn8Rh4kd
GYg5JRb+m2jswA/XfpktRrhWDWjea9xCXdh6QvZRQeHn/cPRQ0xw2XLHdFXKU5GT
zHjXboYWNZTRnh1mDJdkGwLD5oYv0aOSAVMEeTnasDlmgR6St3IqIIQSlKZoeCS2
zThrdERTprzDjmjlcmZJZMc8h6pM2vQ7cpa5f98wATabBkwFIcu/9KZjbAfpUVbF
4RZu3HW4Wv75QjipXrMhtQVyaU2iNWznAvfXs4OOoIZwss7tcyoBz+cCMUXYxLKR
JZLc2/l0+o3Cw/XBHXivF7XwrUtEsELYmW8SkLk+pLQRDBv2nUo0jsAVWC8dCTE=
=b94B
-----END PGP SIGNATURE-----
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext