On Thu, Aug 6, 2015 at 7:55 PM, Lawrence K. Chen, P.Eng. <lkc...@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
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
