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

From: Matthijs Mekking <[email-masked]>
Date: Tue, 3 Apr 2018 14:37:12 +0200

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.

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

   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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 3 Apr 2018 23:22:41 +1000

-- 
Mark Andrews

> On 3 Apr 2018, at 22:37, Matthijs Mekking <[email-masked]> wrote:
> 
> Hi Frederico,
> 
> 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
> Note there is no such thing as an RRSIG RRset. I tried to clarify this in the terminology bis document:
> 
> 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

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 3 Apr 2018 15:28:37 +0200

On 03-04-18 15:22, Mark Andrews wrote:
> 
> -- Mark Andrews
>> On 3 Apr 2018, at 22:37, Matthijs Mekking<[email-masked]>
>> 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.
>>> 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.

If I add a DNSKEY record to the RRset, I would definitely want a new 
RRSIG because the data changed, so the existing signature is no longer 
useful.

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

Implicit RRSIG deletion is only for RRSIG records covering the RRset 
that has changed. It is not meant for re-signing purposes, nor is it 
meant for sophisticated DNSKEY tracking.

- Matthijs

>>> 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.
>> 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 [email-masked] 
>> _______________________________________________ DNSOP mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 3 Apr 2018 22:32:46 -0300

Hi Matthijs,

> 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

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

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

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

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

Fred

---

From: Joe Abley <[email-masked]>
Date: Tue, 3 Apr 2018 23:31:23 -0400

> updated RRsets, only for removed RRsets, explicit or when a removal of

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

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 4 Apr 2018 12:26:31 +0200

Hi Frederico,

> updated RRsets, only for removed RRsets, explicit or when a removal of

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.

Best regards,

Matthijs

> b.example.	ANY	RRSIG A > c.example.	IN	A	192.0.2.5
> c.example.	IN	RRSIG A
> example.	IN	SOA	serial=2
>

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 4 Apr 2018 12:47:01 +0200

Joe,

Thanks for sharing your concerns.

On 04-04-18 05:31, Joe Abley 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.
>>> 
>> 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 [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 4 Apr 2018 23:52:22 +1000

> On 4 Apr 2018, at 8:26 pm, Matthijs Mekking <[email-masked]> wrote:
> 
> Hi Frederico,
> 
> 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.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 5 Apr 2018 09:06:33 +0200

Mark,

> 2 - to perform explicit additions.

If I removed the existing RRSIGs covering "example. A" from the zone, 
now process the next "example A" RR in the MIXFR, that triggers removing 
the same existing RRSIGs, those are already gone and stay gone. That 
seems idempotent to me.

Note that an IXFR client, should only replace an older version with a 
newer version after all the differences have been successfully processed 
(RFC 1995).

The same will be true for MIXFR.

> RRSIGs for such changes though most implementations will do so.

It might be good to add some text for that case. Thanks for bringing it up!

Best regards,
   Matthijs