Uploaded image for project: 'Support'
  1. Support
  2. SUPPORT-156

Two NSEC3PARAM records in signed zone

    XMLWordPrintable

    Details

    • Type: Support
    • Status: Resolved
    • Priority: Minor
    • Resolution: Incomplete
    • Affects Version/s: OpenDNSSEC 1.4.7
    • Fix Version/s: None
    • Component/s: Signer
    • Labels:
      None
    • Environment:

      Suse Linux SLES 11 SP3, x86_64, OpenDNSSEC 1.4.3-develop, Thales HSM

      Description

      I'm seeing a number of zones which have two NSEC3PARAM records in them while most have just one. My understanding of RFC 5155, Section 4 is that there is "the" NSEC3PARAM, in other words there should be one only.

      This is causing us trouble with zones which are transferred to PowerDNS slaves (v 3.4.2) as described at https://github.com/PowerDNS/pdns/issues/2244 because PowerDNS stores one NSEC3PARAM record only, resulting in bogus data.

      However, if, on one of the affected zones I remove OpenDNSSEC tmp/ files and sign the zone, the resulting .axfr file has just one NSEC3PARAM record in it.

      $ cd /var/lib/opendnssec/tmp
      $ mkdir jp-crl
      $ mv crl.xxx-test.* jp-crl/
      $ grep -c NSEC3PARAM jp-crl/crl.xxx-test.axfr
      4
      
      $ preload ods-signer sign crl.xxx-test
      $ sleep 10
      $ grep -c NSEC3PARAM crl.xxx-test.axfr
      3
      

      The zone as served by OpenDNSSEC is valid, however, even with both NSEC3PARAM records in it:

      $ dig @opendnssec xxxx-test AXFR > opendnssec.xfr
      $ ldns-verify-zone opendnssec.xfr
      Zone is verified and complete
      

      Are the two NSEC3PARAM records I'm seeing a bug?

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              yuri Yuri Schaeffer
              Reporter:
              jpmens Jan-Piet Mens
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: