Retrieve DNS resolution results at runtime

[ovadiagal]

Hi there, I'm essentially trying to replicate something similar to this feature by Cloudflare.

Specifically, I'm curious if Envoy can support steps [3] and [5] in the diagram above:

• Step 3: DNS resolver returns a synthetic IP (e.g., 100.80.10.10) for a hostname
• Step 5: When traffic arrives at that synthetic IP's listener, Envoy can recover original hostname that was mapped
  to this IP

I want to recover the original hostname because I want to upgrade traffic to HTTP CONNECT, which requires the original hostname in the CONNECT request.

The use case here is implementing wildcard egress policies (e.g., allow all *.aws.com traffic). With a wildcard policy, I don't know the fully qualified domain names until runtime (when the specific subdomains such as bucket1.aws.com is resolved). I'd prefer not to use SNI so that I can support all kinds of traffic.

Would Envoy be able to:

1. Track DNS resolution mappings (hostname → synthetic IP)
2. Retrieve the original hostname when traffic arrives at the synthetic IP
3. Make this hostname available to the tunneling configuration

Is this a feasible addition to Envoy? Or is there an existing mechanism I'm missing that could achieve this? Thanks in advance ~

[AntonKanug]

In our setup we would use dns_filter for dns resolution, and the aim is to preserve the host and resolved ip mapping and for that mapping to be available in the tcp proxy filter.

[RyanTheOptimist]

cc: @yanavlasov @mattklein123

[AntonKanug]

@yanavlasov @mattklein123 bumping ^, any thoughts on this?

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[agrawroh]

@ovadiagal @AntonKanug I don't think it's supported natively today but it should be possible to write a custom module in GoLang/RUST and load it up via Dynamic Modules. You could make it to an inline lookup, populate a cache for faster subsequent lookup and flush the {hostname, resolved IP} info in Dynamic Metadata or Filter State. You can write another module to map it back to the hostname.

It might also be possible to share the context between two Dynamic Modules.
cc @mathetake

[AntonKanug]

@agrawroh We have given this a shot by writing 2 filters, one in the dns filter to do wildcard dns resolution and store it in a cache, and one to look that cache up from. https://github.com/envoyproxy/envoy/pull/42631/changes

This prototypes provides the needed functionality for our usecase. Given that this is a niche usecase we can cherrypick this change and maintain it in our envoy fork, happy to also get this merged if it adds value to public envoy.

[AntonKanug]

@agrawroh are you/envoy team is open to merging these filters/changes? given these change gives you the features from the cloudflare article linked above all in envoy this seems like something other envoy users could benefit from.

[agrawroh]

@AntonKanug Is it not possible to use Dynamic Modules as I suggested? You could write a GoLang or RUST extension for your use-case. If you do want to contribute and add it then you could do so here in this fork.