> On 4 Apr 2018, at 8:26 pm, Matthijs Mekking <matth...@pletterpet.nl> wrote: > > Hi Frederico, > > On 04-04-18 03:32, Frederico A C Neves wrote: >> Hi Matthijs, >> On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote: >>> Hi Frederico, >>> >>> On 03/29/2018 08:45 PM, Frederico A C Neves wrote: >>>> I was looking at our server to evaluate the MIXFR implementation and >>>> it seams to me that the current text covering dnssec aware client >>>> logic don't take in account that a posterior record at the addition >>>> section, by an MIXFR DNSSEC aware server, will implicitly replace the >>>> RRSIG RRset. >>> >>> I am unclear what case you are covering. >> Any situation that you have an updated RRset. It is implicit that >> you'll have to update the signature, so I was arguing that this is >> afterward covered by 3.6 Replace a RRset. My "simplified" logic take >> this in account to don't impose this extra logic at the client for >> updated RRsets, only for removed RRsets, explicit or when a removal of >> RR causes it. > > I get it now, thanks for clarifying. > > Still, I think the savings in complexity is minimal, since the logic should > exist for RR deletion, so it's a small effort to also enable it for RR > addition. > > Looking at your examples, there is very little difference on the wire. So it > would only be for client logic purposes I assume. I doubt that the logic is > simplified though: > > If you want to prevent implicit RRSIG deletion in the "Replace RRset" case, > you now have to have logic to verify there is no RR in the addition section > of the MIXFR. > > Note that implicit RRSIG deletion is idempotent, so it does not matter if two > RRs in the MIXFR trigger it.
Not if you are processing the additions on a RR by RR basis. You can add a new RRSIG before you add the covering RR. You need to perform two passes over the addition section. 1 - to perform implicit deletions. 2 - to perform explicit additions. Note there are some RR deletions / addition pairs that DO NOT change RRSIGs. e.g. case changes in domain names that are subject to canonicalisation. There is no requirement to regenerate RRSIGs for such changes though most implementations will do so. > Best regards, > > Matthijs > > >> So the actual difference on the wire is one server replacing the RRSIG >> and the other adding it. For the client processing is RRSIG removal >> logic only at RRset removal in one case and at any change for the >> other. Bellow a zone at serial 1 and 2 and the two MIXFR versions. >> example. IN SOA serial=1 >> example. IN RRSIG SOA >> a.example. IN A 192.0.2.1 >> a.example. IN RRSIG A >> b.example. IN A 192.0.2.2 >> b.example. IN A 192.0.2.3 >> b.example. IN RRSIG A >> example. IN SOA serial=2 >> example. IN RRSIG SOA >> b.example. IN A 192.0.2.3 >> b.example. IN A 192.0.2.4 >> b.example. IN RRSIG A >> c.example. IN A 192.0.2.5 >> c.example. IN RRSIG A >> # "simplified MIXFR" >> example. IN SOA serial=2 >> example. IN SOA serial=1 >> a.example. ANY A >> b.example. IN A 192.0.2.2 >> example. IN SOA serial=2 >> b.example. IN A 192.0.2.4 >> b.example. ANY RRSIG A > c.example. IN A 192.0.2.5 >> c.example. IN RRSIG A >> example. IN SOA serial=2 >> # "implicit RRSIG removal at any change" >> example. IN SOA serial=2 >> example. IN SOA serial=1 >> a.example. ANY A >> b.example. IN A 192.0.2.2 >> example. IN SOA serial=2 >> b.example. IN A 192.0.2.4 >> b.example. IN RRSIG A >> c.example. IN A 192.0.2.5 >> c.example. IN RRSIG A >> example. IN SOA serial=2 >>> >>>> Logic could be simplified only to Deletions of RRs, when they conclude >>>> a removal of a RRset, or RRsets by itself. >>> >>> No, also if there is an RR addition, it means the RRset has changed, so >>> existing RRSIG records can be implicitly removed. >>> >> That is true but in this case you imply that it will be later added. I >> was proposing to replace it. >>>> All the other cases, addition or replacement, will be covered >>>> automatically by an addition or replace of a RRSIG RRset. There is no >>>> need to extra client logic to remove RRSIG, at addition of a RR, and >>>> at deletion of a RR if it not remove the RRset. >>> >>> Note there is no such thing as an RRSIG RRset. I tried to clarify this >>> in the terminology bis document: >> So how do you call, two RR for the same name, type and class in a >> double signed zone? Never mind I was not aware of this, thanks! Change >> "a RRSIG RRset" by "any RRSIGs" and the logic still stands. >>> >>> https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html >>> >>> Note that adding an RRSIG is different than replacing an RRSIG. >> Ok, but we could achive the same end result with both logics and >> operations. >>> >>>> This is documented as issue #10 and includes proposed text. >>>> >>>> https://github.com/matje/mixfr/issues/10 >>> >>> I think it makes more sense to keep the text as is, that is when >>> changing an RRset implicitly remove the corresponding RRSIG records. I >>> am opposed to only removing corresponding RRSIG on a RR deletion. >>> >> I think my version is easyer imposing less checks on clients but I can >> live with the current text >> I just realized the draft needs a new example for 4.2. The current one >> is based on "Delete All RRsets of a Type". This operations was removed >> in the current version of the draft. >>> Best regards, >>> Matthijs >> Fred > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
