Subject: Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case

From: Richard Lamb <[email-masked]>
Date: Tue, 24 Mar 2015 16:24:46 -0500

Fwiw i believe there is a clear need for this work.  Having been involved
with various early DNSSec deployment efforts, the diminished value of ixfr
has resulted in a few different home grown hybrid solutions to capture the
efficiency of rsync with added notification functionality.  It would be
good if we just "fixed" ixfr.  -Rick

On Thursday, January 15, 2015, Matthijs Mekking <[email-masked]>
wrote:

> Hi wg,
>
> IXFR with DNSSEC is suddenly not so small anymore. Do you recognize
> this? Olafur and I have some ideas on keeping those zone transfers
> small. Your feedback is appreciated.
>
>   http://www.ietf.org/internet-drafts/draft-mekking-mixfr-01.txt
>
> Best regards,
>   Matthijs
>
> _______________________________________________
> DNSOP mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: John Dickinson <[email-masked]>
Date: Tue, 24 Mar 2015 21:41:17 -0500

> On Thursday, January 15, 2015, Matthijs Mekking <[email-masked]> wrote:
> Hi wg,
> 

I support this draft. One thing that jumped out to me was there appears to be no mention of NSEC/NSEC3 chain management when adding/removing records.

regards
John

---

From: Tony Finch <[email-masked]>
Date: Wed, 25 Mar 2015 11:00:11 +0000

John Dickinson <[email-masked]> wrote:
>
> I support this draft. One thing that jumped out to me was there appears
> to be no mention of NSEC/NSEC3 chain management when adding/removing
> records.

Even if the slave is able to work out what the necessary changes are to
the NSEC chain, the master is still going to have to send the new RRSIG
records. So I don't think there would be much saving from adding special
cases for NSEC and NSEC3.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southwest Forties, Cromarty, Forth, Tyne, Dogger: Variable 4 becoming
southerly or southeasterly 4 or 5, occasionally 6 later. Slight becoming
moderate. Showers. Good, occasionally moderate.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Mar 2015 23:33:39 +1100

> cases for NSEC and NSEC3.

NSEC is a singleton record.  Adding a new one indicates a implicit
deletion of any other NSEC record at that name.  This does not
indicate that all NSEC deletes can be removed from the IXFR stream,
when constructing a MIXFR stream, only those with a matching addition.

Adding a NSEC3 record causes a implicit deletion of the existing
NSEC3 with matching parameters.  This does not indicate that all
NSEC3 deletes can be remove from the IXFR stream, when constructing
a MIXFR stream, only those with a matching addition.

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

---

From: Tony Finch <[email-masked]>
Date: Wed, 25 Mar 2015 12:42:25 +0000

Mark Andrews <[email-masked]> wrote:
> deletion of any other NSEC record at that name.

Right, and MIXFR already has a general-purpose mechanism for that.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Wight, Portland, Plymouth: North 4 or 5 backing southwest 5 to 7, perhaps gale
8 later. Slight or moderate, becoming moderate or rough. Fair then rain. Good,
becoming moderate or poor.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 26 Mar 2015 00:24:27 -0400

> On Mar 25, 2015, at 8:33 AM, Mark Andrews <[email-masked]> wrote:
> 
> 

The only cases where MIXFR can safe in the case of NSEC3 are
a) add of updated NSEC3 with same owner name as singleton the old one is deleted
b) replacement of NSEC3PARM implies that the NSEC3’s matching old NSEC3PARAM can be deleted. 

Olafur

---

From: Mark Andrews <[email-masked]>
Date: Thu, 26 Mar 2015 20:31:05 +1100

In message <[email-masked]>, Olafur Gudmundsson writes:
> > In message
> <[email-masked]>, Tony Finch
> writes:

NSEC3 is not a singlton.  It is a quasi singleton record.  Two
chains may have names that hash to the same value which is why I
said to check the parameters.  Statistically this is extremely
unlikely but it is easy to check to ensure that you are not removing
from a different chain.  Named already does this check when rebuilding
NSEC3 chains after processing a UPDATE mesaage.

> NSEC3PARAM can be deleted.

Multiple NSEC3PARAM records are permitted.  A server only needs to
pick one when generating a reply.  There is zero requirement for a
server to delete all NSEC3 records that make up a NSEC3 chain
atomically.  Named doesn't do this today and I have no intention
of making the incremental management of NSEC/NSEC3 constuction /
destruction do this.  This work is deliberatly broken up to allow
a server to appear to simultaneously answer queries, to rebuild/destroy
NSEC/NSEC3 chains in zones and to accept new updates without having
to rely on the OS supporting threads.

NSEC3PARAM -> NSEC3 inference you are describing above depends on
atomicity of changes which just do not happen and cannot be made
to happen without detremental effects.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 27 Mar 2015 13:29:42 +0000

On 3/26/15, 4:31, "Mark Andrews" <[email-masked]> wrote:
>Named doesn't do this today and I have no intention

In the same line of reasoning - what about replacement of signatures.  For
zones where signatures are refreshed en mass, is there code-logic that
decides to delete signatures because new ones are being added.

>to happen without detremental effects.

One of the ideas I am thinking of is - when DNSSEC was designed there was
little operational reality to draw upon.  Having multiple signatures was
imagined and built into the protocol - for example, you could sign with
RSA-SHA1 for Monday and the next signature for Tuesday, and so on.  (We
didn't consider packet size and we anticipated an air gap between signer
and server.  Life was much different back then.)  So today, the protocol
is more flexible when it comes to having signatures than is needed.  With
the onset of operations a couple of things arise - rarely does anyone have
multiple algorithms and rarely does anyone have multiple active keys, so
usually, its a one-signature affair.

Under that reality one can derive heuristics about what to implicitly
drop.  Heuristics are inherently imperfect, hence some risk they
misbehave.  But given that MIXFR can be designed to be an option to using
AXFR and IXFR, it might work that defining heuristics works here.  I'm not
sold, and it goes against my thoughts we need to simplify rather than
complexify (yes, not a word) the protocol, but its worth a discussion.
Should we include some basic set of heuristic rules for implicitly
deleting records.

In a conversation, it was noted that AXFR is MIXFR in the extreme - it
says "add all this" and implicitly "delete all that."  IXFR is a diff that
explicitly lists the delta.  MIXFR sounds like an intermediate step
between the two, a little of the delta of IXFR and the implicit deleting
of a records from sets.

Or - perhaps MIXFR shouldn't be grafted off IXFR and be grafted off of
dynamic update.  That means a different wire format and instead of
implicit deletes, you get selective deletes according to rules for
matching.  See "Dynamic Updates in the Domain Name System (DNS UPDATE) "
[aka RFC 2136] sections 2.5.2, 2.5.3, and 2.5.4 for what I'm calling
"selective deletes."  At first I didn't like this idea, but when thinking
about the implicit delete situation, perhaps the RFC2136-like semantics
are better.  (Perhaps.)