Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rec: If serving stale, wipe CNAME records from cache when we get a NODATA negative response for them #13353

Merged
merged 2 commits into from Oct 16, 2023

Conversation

omoerbeek
Copy link
Member

PR #12395 already did that for the NXDOMAIN case.

Short description

Checklist

I have:

  • read the CONTRIBUTING.md document
  • compiled this code
  • tested this code
  • included documentation (including possible behaviour changes)
  • documented the code
  • added or modified regression test(s)
  • added or modified unit test(s)

…negative response for them

PR PowerDNS#12395 already did that for the NXDOMAIN case.
@coveralls
Copy link

coveralls commented Oct 11, 2023

Pull Request Test Coverage Report for Build 6483780494

  • 129 of 130 (99.23%) changed or added relevant lines in 2 files are covered.
  • 12 unchanged lines in 4 files lost coverage.
  • Overall coverage increased (+1.3%) to 56.419%

Changes Missing Coverage Covered Lines Changed/Added Lines %
pdns/recursordist/test-syncres_cc10.cc 126 127 99.21%
Files with Coverage Reduction New Missed Lines %
pdns/packethandler.cc 1 72.4%
pdns/dnsdistdist/dnsdist-async.cc 2 82.21%
pdns/rcpgenerator.cc 3 89.55%
pdns/recursordist/test-syncres_cc1.cc 6 89.56%
Totals Coverage Status
Change from base Build 6483746534: 1.3%
Covered Lines: 102492
Relevant Lines: 151256

💛 - Coveralls

@@ -4747,7 +4747,7 @@ dState SyncRes::getDenialValidationState(const NegCache::NegCacheEntry& ne, cons
return getDenial(csp, ne.d_name, ne.d_qtype.getCode(), referralToUnsigned, expectedState == dState::NXQTYPE, LogObject(prefix));
}

bool SyncRes::processRecords(const std::string& prefix, const DNSName& qname, const QType qtype, const DNSName& auth, LWResult& lwr, const bool sendRDQuery, vector<DNSRecord>& ret, set<DNSName>& nsset, DNSName& newtarget, DNSName& newauth, bool& realreferral, bool& negindic, vState& state, const bool needWildcardProof, const bool gatherWildcardProof, const unsigned int wildcardLabelsCount, int& rcode, bool& negIndicHasSignatures, unsigned int depth)
bool SyncRes::processRecords(const std::string& prefix, const DNSName& qname, const QType qtype, const DNSName& auth, LWResult& lwr, const bool sendRDQuery, vector<DNSRecord>& ret, set<DNSName>& nsset, DNSName& newtarget, DNSName& newauth, bool& realreferral, bool& negindic, vState& state, const bool needWildcardProof, const bool gatherWildcardProof, const unsigned int wildcardLabelsCount, int& rcode, bool& negIndicHasSignatures, unsigned int depth) // NOLINT(readability-function-cognitive-complexity)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's unaffected by the CI clang-tidy I'd rather remove the // NOLINT here and (potentially at a later point) fix the function implementation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's unaffected by the CI clang-tidy I'd rather remove the // NOLINT here and (potentially at a later point) fix the function implementation.

I'll remove it and see if it's filtered out.

// serve-stale is active. Avoid that by explicitly zapping that CNAME record.
if (qtype == QType::CNAME && MemRecursorCache::s_maxServedStaleExtensions > 0) {
g_recCache->doWipeCache(qname, false, qtype);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to also wipe the cache line 4999? I guess we do not because for DS we take care of doing a lookup for the exact type (positive and negative) first, before looking at a possible CNAME, but it feels a bit weird to have a different behaviour in that case.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that was my reasoning. It would not hurt though, I believe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants