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

DNS-based CWNPs not reliable on hostnames with constantly changing IPs #186

Open
mreiger opened this issue Aug 27, 2024 · 1 comment · May be fixed by #187
Open

DNS-based CWNPs not reliable on hostnames with constantly changing IPs #186

mreiger opened this issue Aug 27, 2024 · 1 comment · May be fixed by #187
Assignees

Comments

@mreiger
Copy link
Contributor

mreiger commented Aug 27, 2024

When resolving DNS names that have a huge IP address pool (eg on AWS), the usual behaviour of DNS servers is to return a limited subset of IPs (say, 8 IP addresses) at random. When asked again, another set of random IPs is returned.

Currently the DNS cache is implemented in a way where the content of a DNS reply completely overwrites the cache entry for this hostname. This can lead to a race condition with concurrent DNS queries: When two pods query the same hostname in parallel, and the reply to the second pod's DNS query comes between the reply to the first pod's DNS query and the actual request to the target IP by the first pod, the IP may already be overwritten in the DNS cache and therefore also the firewall ruleset, making the request from the first pod fail.

A possible solution would be:
Store each IP in the DNS cache with its associated TTL value, add new IPs from subsequent replies instead of replacing the whole entry, and age out old IPs when they exceed their TTL.

@mreiger mreiger linked a pull request Aug 29, 2024 that will close this issue
@mreiger mreiger self-assigned this Aug 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants
@mreiger and others