Relax ADDITIONAL TTL capping checks
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.
Showing with 3 additions and 3 deletions