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

Problems when a change in delegation cause A RRs to become glue RRs

    XMLWordPrintable

    Details

    • Type: Support
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: OpenDNSSEC 1.3.8, OpenDNSSEC 1.4.0a2
    • Fix Version/s: None
    • Component/s: Signer
    • Labels:
      None
    • Environment:

      (Running the 1.3-branch, rev. 6352 on a RHEL 5.8 32bit system).

      Description

      I noticed what I believe is a problem with OpenDNSSEC when a change in
      delegation of subdomains cause normal A-RRs to become glue A-RRs.
      (Running the 1.3-branch, rev. 6352 on a RHEL 5.8 32bit system).

      Before the delegation is changed, the A-RRs should be (and are)
      signed, but when the A-RRs becomes glue they should not.

      I recreated the problem in a test zone. I've saved the
      unsigned and signed zone-files for the different phases in
      the test case and can send them if so requested (or open
      a case if that is preferred).

      I don't know exactly when the RRSIG for the A-RRs in question
      (that transitioned from normal A-RRs to glue RRs) should be removed,
      but I assume it should be done immediately after the change.

      In any case, ODS seems to:

      1 Keep the signatures after the change.
      2 Not process them (e.g. update them if they should
      be recalculated).
      3 Cause NSEC3 issues.

      In my case (the "live one", not the test) the (partial) auditor complained
      Jun 13 19:16:39 ns-test ods-auditor[17437]: chalmers.se : Signature expiration (1339853028) for green.net.chalmers.se., A should be later than (the refresh period (259200) - the resign period (3600)) from now (1339607799)

      I think this is because the signature was to be recalculated
      at the next run, but then the delegation was changed so the
      A RR was glue and ODS didn't process the RRSIG at all (2 above).

      I'm also surprised that the auditor didn't complain over
      the fact that the glue A-RRs were signed. If I remember correct
      it used to do that, but maybe only i full mode?

      In the test-case, a full audit after the delegation was changed
      and the zone resigned gave the following output:
      [root@ns-test unsigned]# ods-auditor -f -z test.eu
      Auditor started
      Auditor starting on test.eu
      6: test.eu : SOA differs : from 1 to 2012061403
      6: test.eu : Auditing test.eu zone : NSEC3 SIGNED
      3: test.eu : Found RRs for ns3.dom.test.eu (f6arn3nl2f2tog71r9jegncjiaid1ts0.test.eu) which was not covered by an NSEC3 record
      3: test.eu : Found RRs for ns1.dom.test.eu (gip7rppf16ufvqmlbq537gk6ni77ma9s.test.eu) which was not covered by an NSEC3 record
      3: test.eu : Found RRs for ns2.dom.test.eu (sphlgq22pk3uga2t1f3tccbqf4hfu0p9.test.eu) which was not covered by an NSEC3 record
      6: test.eu : Finished auditing test.eu zone
      Auditor found errors - check log for details

      Indicate that the RRSIGs shouldn't be there.

      Manually removing the RRSIGs for the glue A RRs from
      the zone made the auditor run without complains,
      so maybe the root of these problems is that the
      RRSIGs for the A-RRs that became glue are left
      in the signed zone?

      Also - ODS does not generate RRSIG for glue-RRs
      in general. Removing one of the glue-RRs in the
      test case, resign, add it again, a resign does
      not recreate a RRSIG for the glue RR. This too
      indicate that the problem is that the RRSIGs are
      "left" in the signed zone when the delegation is changed.

      Comments?

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              matthijs Matthijs Mekking
              Reporter:
              goeran Göran Bengtson
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: