Hi Frederico,
On 04-04-18 03:32, Frederico A C Neves wrote:
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.
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
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
