Always expecting a TTL of exactly 300 seconds for RRsets found in the
ADDITIONAL section of responses received for CD=1 queries sent during
TTL capping checks is too strict since these responses will contain
records cached from multiple DNS messages received during the resolution
process.

In responses to queries sent with CD=1, ns.expiring.example/A in the
ADDITIONAL section will come from a delegation returned by ns2 while the
ANSWER section will come from an authoritative answer returned by ns3.
If the queries to ns2 and ns3 happen at different Unix timestamps,
RRsets cached from the older response will have a different TTL by the
time they are returned to dig, triggering a false positive.

Allow a safety margin of 60 seconds for checks inspecting the ADDITIONAL
section of responses to queries sent with CD=1 to fix the issue.  A
safety margin this large is likely overkill, but it is used nevertheless
for consistency with similar safety margins used in other TTL capping
checks.