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

[Frederico A C Neves <[e-mail]>]

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.

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