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

Integrate the DNS search domain fallbacks #23

Open
wants to merge 1 commit into
base: dns_domains_fallback_reverse
Choose a base branch
from

Conversation

FR4NK-W
Copy link
Contributor

@FR4NK-W FR4NK-W commented Nov 8, 2024

Make use of the DNS search domain fallbacks:
If no DNS search domain is discovered by the other hinters before the timeout is about to expire, use the public IP(s) of the host and reverse DNS to discover candidate DNS search domains. If there are no public IPs, use external DNS servers to discover publicly reachable IPs.

Make use of the DNS search domain fallbacks:
If no DNS search domain is discovered by the other hinters before the timeout is about to expire,
use the public IP(s) of the host and reverse DNS to discover candidate DNS search domains.
If there are no public IPs, use external DNS servers to discover publicly reachable IPs.
@FR4NK-W FR4NK-W requested a review from marcfrei November 8, 2024 14:56
Copy link
Member

@marcfrei marcfrei left a comment

Choose a reason for hiding this comment

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

LGTM

@FR4NK-W
Copy link
Contributor Author

FR4NK-W commented Nov 18, 2024

@marcfrei : You mentioned some potential concerns about sending more information than strictly necessary about the host environment to a third party in #22 :

Could this raise privacy concerns, since we are leaking information to external services?

These DNS fallbacks are explicitly only used when there is no local DNS search domains configured and all other methods failed. The only information leaked is the external IP address. This does not provide external services (Akamai, Quad9) with any other information they would not get when querying the DNS system for one of their hosts.
We only use the external DNS resolver if required for getting a reply.

Let's discuss further in PR #23 ?

As mentioned in #22, I believe the information obtained by the third party, specifically the external IP of the host, is only provided if necessary for the bootstrapper to work, and only when the other mechanisms for obtaining a search domain failled. So only in

ip, err := queryExternalIP()
we use DNS to resolve an external IP, which is no different from using an open resolver, except that the only query we do is related to the host IP and no hostname or search domain information is shared.

Now, using an external resolver could raise concerns in a split DNS environment, where direct communication with external resolvers is explicitly not desired.
If you think this is a valid concern, we could add some additional mitigations for it, e.g. after

nameservers, err := resolver.LookupNS(ctx, akamaiDomain)
by explicitly checking which type of error occurred, before resorting to using the external open resolver. For example, we could abort the fallback if we receive a NXDOMAIN response, since we know that the record should exist and is deliberately shadowed if we get such a response.

Please let me know if you can think of any other information exposure!

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 this pull request may close these issues.

2 participants