Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

[Matthijs Mekking <[e-mail]>]

Joe,

Thanks for sharing your concerns.

On 04-04-18 05:31, Joe Abley wrote:
> On Apr 3, 2018, at 21:32, Frederico A C Neves <[e-mail]>
> 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.

I am happy to entertain you by telling that there is no shift in 
responsibility for coherency in the contents of a zone.

We are merely trying to come up with a more sophisticated syntax such 
that the primary has to use less bytes to achieve zone consistency.


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

I see your argument. On the other hand, if you make a mistake with 
DNSSEC you are in trouble anyway.


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

Note that this does not affect resolvers and caches: zone transfers are 
between authoritative name servers only.

I am determined to back the specification with an implementation, 
especially after the camel is our new favorite animal, so hopefully that 
will take away your concerns regarding implementation complexity.


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

It is zone transfer size. It can be quite large with DNSSEC (zone 
re-sign, NSEC3 resalt). To quote someone: Reducing the amount of data, 
is the only way to keep up with our current and future workloads.

Best regards,
   Matthijs


> 
> 
> Joe _______________________________________________ DNSOP mailing
> list [e-mail] https://www.ietf.org/mailman/listinfo/dnsop
>