Skip to content

Add command line flags for extra DNS flexibility.#71

Merged
NullHypothesis merged 1 commit into
masterfrom
add-dns-forwarder
May 26, 2026
Merged

Add command line flags for extra DNS flexibility.#71
NullHypothesis merged 1 commit into
masterfrom
add-dns-forwarder

Conversation

@NullHypothesis
Copy link
Copy Markdown
Contributor

@NullHypothesis NullHypothesis commented May 23, 2026

Users currently have little flexibility in how their enclave uses DNS: veil-daemon's -resolver flag is all there is. Users however may also want to configure search domains, or have the enclave's DNS handled like the EC2 host's. To make all of that possible, this PR introduces new command line flags to both veil-daemon and veil-proxy.

The proxy now has -dns-forwarder. When enabled, it instructs the proxy to open both a UDP and TCP listener on port 53 on the tun interface. All incoming payload (the forwarder has no understanding of DNS; it simply shuffles around bytes) is then blindly forwarded to the EC2 host's nameservers configured in /etc/resolv.conf.

The daemon now has -dns-search, -dns-ndots, and the PR also renames -resolver to -dns-resolver for consistency. The two new flags allow users to provide the search domains and ndots option, both of which are written to the enclave's /etc/resolve.conf.

To make use of these features, start veil-proxy with the new flag:

veil-proxy -dns-forwarder

Then, set veil-daemon's resolver to the host's IP address, and you can also provide search domains and ndots:

veil-daemon \
    -dns-resolver 10.0.0.1 \
    -dns-search "cluster.local" \
    -dns-ndots 2

Fixes #61.

Users currently have little flexibility in how their enclave uses DNS:
veil-daemon's -resolver flag is all there is. Users however may also
want to configure search domains, or have the enclave's DNS handled like
the EC2 host's. To make all of that possible, this PR introduces new
command line flags to both veil-daemon and veil-proxy.

The proxy now has `-dns-forwarder`.  When enabled, it instructs the
proxy to open both a UDP and TCP listener on port 53 on the tun
interface. All incoming payload (the forwarder has no understanding of
DNS; it simply shuffles around bytes) is then blindly forwarded to the
EC2 host's nameservers configured in /etc/resolv.conf.

The daemon now has `-dns-search`, `-dns-ndots`, and the PR also renames
`-resolver` to `-dns-resolver` for consistency. The two new flags allow
users to provide the search domains and ndots option, both of which are
written to the enclave's /etc/resolve.conf.

To make use of these features, start veil-proxy with the new flag:

    veil-proxy -dns-forwarder

Then, set veil-daemon's resolver to the host's IP address, and you can
also provide search domains and ndots:

    veil-daemon \
        -dns-resolver 10.0.0.1 \
        -dns-search "cluster.local" \
        -dns-ndots 2

Fixes #61.
@NullHypothesis
Copy link
Copy Markdown
Contributor Author

@jalaziz, this should address your needs, no?

@jalaziz
Copy link
Copy Markdown

jalaziz commented May 24, 2026

@jalaziz, this should address your needs, no?

Apologies for the delay! Do you still need an EC2 instance for testing?

This should work great! It would be slightly nicer if there was an option for the proxy to handle the recursive lookup using the host's setting (so that the daemon can just defer to the proxy), but that's more of a nice to have.

@NullHypothesis
Copy link
Copy Markdown
Contributor Author

Do you still need an EC2 instance for testing?

Yes, this still needs testing. I can either test it myself if you can provide an EC2 instance, or you can test yourself if you prefer, and let me know if it all works. make enclave-test should run the test suite inside the enclave.

It would be slightly nicer if there was an option for the proxy to handle the recursive lookup using the host's setting (so that the daemon can just defer to the proxy), but that's more of a nice to have.

Right, this would improve UX but it requires more complexity than I'm comfortable introducing. I prefer the forwarding mechanism to be protocol-agnostic.

@jalaziz
Copy link
Copy Markdown

jalaziz commented May 26, 2026

Right, this would improve UX but it requires more complexity than I'm comfortable introducing. I prefer the forwarding mechanism to be protocol-agnostic.

Entirely fair.

@NullHypothesis
Copy link
Copy Markdown
Contributor Author

Ok, this generally works. Ran into a few minor (and unrelated) issues that I'll address in separate pull requests.

@NullHypothesis NullHypothesis merged commit 5f29743 into master May 26, 2026
9 checks passed
@NullHypothesis NullHypothesis deleted the add-dns-forwarder branch May 26, 2026 12:47
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.

Default resolver and search domains

2 participants