do not stupidly delete ZSK files

[Casey Deccio]

On Thu, Aug 6, 2015 at 7:55 PM, Lawrence K. Chen, P.Eng. <lkchen at ksu.edu>
wrote:

> Ok, so way back then....they were running servers that didn't support
> NSEC3 RRs and it had nothing to do with what algorithm we were using....5
> for RSASHA1 or 7 for RSASHA1-NSEC3-SHA1.
>

DNSSEC introduces: new records (and types) into a zone; new protocol
requirements on servers; and a variety of crypto algorithms.  As far as the
new records are concerned, they are transferred between authoritative
servers (primaries and secondaries) like other records in the zone--even
servers that aren't fully DNSSEC aware should be able to handle this.  With
regard to protocol requirements, even if an authoritative server has the
appropriate DNSSEC records, it must know how to serve them in response to
queries.  This includes serving the RRSIGs with RRsets, serving NSEC or
NSEC3 for authenticated denial of existence (negative responses and
wildcards), serving DS records from the parent zone, etc.  However, some of
these protocol requirements have been incremental (e.g, NSEC3), which is
why algorithms 6 and 7 were introduced--same algorithms as 3 and 5, new
protocol requirements for servers.  So... while algorithms don't
necessarily need to be understood by the authoritative servers (because
they're not doing the validating), protocol requirements do.

In short: the DNSSEC records were probably being transferred correctly, and
the secondaries probably supported DNSSEC but not NSEC3, but the algorithms
themselves didn't matter to the authoritative server.

Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150806/6316a2b0/attachment.html>