On Apr 3, 2018, at 21:32, Frederico A C Neves <fne...@registro.br> wrote:
>> 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 have not been reading this thread in depth and so I have not commented up until now. But I sense that there is a proposed shift of responsibility for coherency in the contents of a zone, specifically with resapect to DNSSEC. Quite possibly I am wrong, in which case I will enjoy being told as much. If I am a zone administrator, responsible for the self-consistent contents of my zone, and I make a mistake, the behaviour today (with zones distributed by AXFR, IXFR, rsync, ftp, avian carrier) is that a DNS zone is a DNS zone and the RRSets contained within are simply that, no appreciation, understanding or accommodation of DNSSEC required. The line of thinking inherent in the lowest quoted paragraph above suggests that distribution of sets of RRSets (together forming a zone) must with this new transfer mechanism be completed with semantic appreciation for the relationship between non-RRSIG-type RRSets and the corresponding RRSIG-type RRSets that accompany them in a signed zone. This worries me. The protocol requirements for DNSSEC as described in RFC 4035 are non-trivial to implement already (cf. the treatment of RRSets in a response with their accompanying RRSIG RRSets as an atomic unit in the cache, to be expired together regardless of differences in TTL) and I don't think we want to extend them without good reason. If we expect MIXFR (or whatever it is eventually called) to behave differently in this respect to AXFR, IXFR or any number of out-of-band transfer mechanisms, we should have a good reason for it. I don't know that I see one, yet. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
