-- 
Mark Andrews

> On 3 Apr 2018, at 22:37, Matthijs Mekking <matth...@pletterpet.nl> 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.
> 
> 
>> 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.

Poor logic. Take the case where you add a new algorithm to the DNSKEY RRset 
there is no requirement to update existing RRSIG.

Even when re-signing you can’t remove RRSIG with the same key id unless you 
know that the server prevents duplicate key ids.  For the general case you need 
to validate the RRset against the RRSIG to give the DNSKEY then you can delete 
RRSIGs generated from that DNSKEY. 

>> All the other canonrequirementses, 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:
> 
>  https://www.ietf.org/mail-archive/web/dnsop/current/msg22118.html
> 
> Note that adding an RRSIG is different than replacing an RRSIG.
> 
> 
>> 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.
> 
> Best regards,
>  Matthijs
> 
> 
>> Fred
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to