On 3/26/15, 4:31, "Mark Andrews" <ma...@isc.org> wrote: >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.
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. >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. 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.)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
