daemon: Implement DELETE /fqdn/cache API #6692
Conversation
|
test-me-please |
|
test-me-please |
|
test-me-please |
1 similar comment
|
test-me-please |
|
test-me-please |
| generatedRules, namesMissingIPs := gen.GenerateRulesFromSources(rulesToUpdate) | ||
| if len(namesMissingIPs) != 0 { | ||
| log.WithField(logfields.DNSName, strings.Join(namesMissingIPs, ",")). | ||
| Warn("Missing IPs for ToFQDN rule") |
There was a problem hiding this comment.
This is a warning stating there are missing IPs for ToFQDN, Is this a user problem? If yes, what can the user to to workaround this problem?
There was a problem hiding this comment.
It is a problem for them, assuming they included a matchName but no IPs are known for it. The only instructions I can think to include would be a little complicated. Something like:
Missing IPs for toFQDN rule. Ensure DNS data exists via the DNS Proxy or DNS Polling.
This used to also say: Using stale data or something like that. This line is copied from the function above.
There was a problem hiding this comment.
I'm not sure I understand the warning. Why is it a problem if no IPs are in the cache for a matchName?
There was a problem hiding this comment.
This is inherited from the DNS poller days, and it is less useful with the proxy. Let's say I include
toFQDNS:
- matchName: foo.com
- matchName: bar.com
If the poller can't resolve these, it means the policy will never work as intended. This warning is the only indication of this (there might also be a timeout error, actually). In the proxy case it is less clear that it's a problem. In that case if a lookup for foo.com happens, bar.com still has no data but that might be ok. In that case, it is more confusing. We now have an api to list the IPs in the DNS cache, so we can check foo.com and bar.com and this is less of an issue.
Are you saying it can be an info? or a debug? I'm ok with either, I guess, since I don't know how to make this reasonable in the dns proxy case.
|
test-me-please |
|
@aanm @eloycoto @ianvernon I realised I had bugs with the CIDR handling, and fixing it caused a lot more complexity. Since it isn't clearly needed I removed it. The code is largely the same, but with fewer lines of additional code. |
|
test-me-please |
In normal operation, the cache will only expire entries after the TTL. In some circumstances, we will need to forcibly clear part of the cache without removing all the data within it. ForceExpire and the updated removeExpired allow doing this per-name and by LookupTime. Signed-off-by: Ray Bejjani <ray@covalent.io>
There are circumstances to trigger a rule regeneration without new IP information (such as a cache clear or TTL expiration without a new DNS event). ForceGenerateDNS allows running logic similar to UpdateGenerateDNS, where DNS names are matched against rules and new versions generated. Signed-off-by: Ray Bejjani <ray@covalent.io>
Signed-off-by: Ray Bejjani <ray@covalent.io>
This removes entries that match the matchName or CIDR, removing lookups that occurred before the time the API call was issued. No-parameter invocations will clear the entire cache. Signed-off-by: Ray Bejjani <ray@covalent.io>
|
test-me-please |
|
test-me-please |
| generatedRules, namesMissingIPs := gen.GenerateRulesFromSources(rulesToUpdate) | ||
| if len(namesMissingIPs) != 0 { | ||
| log.WithField(logfields.DNSName, strings.Join(namesMissingIPs, ",")). | ||
| Warn("Missing IPs for ToFQDN rule") |
There was a problem hiding this comment.
I'm not sure I understand the warning. Why is it a problem if no IPs are in the cache for a matchName?
|
I agree with @aanm that the warning is a bit weird. I would not know what to do as a user. Other pieces look good though so I'm merging this. |
This removes entries that match the matchName or CIDR, removing lookups
that occurred before the time the API call was issued. No-parameter
invocations will clear the entire cache.
This change is