Modify hostname after table match is found and before DNS lookup

[aniapte]

Hello,

We're running on AWS infrastructure. Our sniproxy usecase is that clients connect to external-foo1.bar.com which maps to the sniproxy machine. This needs to be routed to foo1.bar.com. Now, foo1.bar.com can be resolved externally to ec2 external ip and internally to a 10.x.x.x ip. The number of backends may change, so it could be foo9.bar.com. To save sniproxy.conf maintenance work, I was exploring using the * wildcard as the target.

Could you please comment on the feasibility of altering the incoming hostname so that external-foo1.bar.com is routed to foo1.bar.com. If this is possible I need not maintain another DNS resolver to resolve external-foo1.bar.com to an internal aws ip address.

I have a patch for such a directive here: https://github.com/aniapte/sniproxy/commit/462f6aef01da41c8ab1b8f00197e6e698b80475a

How likely is this to get accepted into the mainline.

thanks aniapte

[aniapte]

Let me explain my req in a better way.

I have many backends foo1.bar.com to foo100.bar.com. These are in aws vpc so they are not publicly addressable. Incoming requests come to sniproxy running on a publicly addressable machine. Incoming requests use hostnames like external-foo1.bar.com to external-foo100.bar.com. I want to be able to route them to the back ends by removing the external- prefix. foo1.bar.com can be resolved to an internal IP address but external requests can't use that hostname because of app specific reasons.

thanks

[dlundquist]

@aniapte I just commented on your commit above. Fundamentally I think modification of the protocol is outside of the scope of SNIProxy since it doesn't track the state of the protocol after the initial client request. For TLS this is not possible without the terminating the TLS session, which requires the private keys of the backend server. Terminating TLS is outside of the niche that SNIProxy fills, you could use Apache with mod_rewrite for example.

[aniapte]

@dlundquist, I don't want to modify the protocol. This is just a new way of choosing the backend. Instead of static table entries in the conf file this is kind of a dynamic way of choosing backends. A variation of the wildcard table option. One advantage of thus approach is it allows scaling backends without changing the conf file.

[dlundquist]

@aniapte That's what I get for trying to respond before coffee...

So if I understand you correctly, you want to leverage the DNS resolver functionality using a different hostname than the one supplied in the client request. Currently SNIProxy does support hostnames as backend target addresses e.g.:

   table foo {
       ^foo\.example\.com$ baz.example.com
   }

But you would like to do preform these dynamically, rather than listing each hostname mapping explicitly. It seems like a regular expression replacement with back references would be the most flexible way to do this. Is this on the right track?

[aniapte]

@dlundquist Yep you got it! I'd like to do the mappings dynamically, a regex replacement.

[aniapte]

Since pcre doesn't have inbuilt support for substitution, I was searching for something that could do substitutions using pcre. There's a wrapper (pcrs) to do just that: http://stackoverflow.com/a/8053974

[aniapte]

@dlundquist, if this feature looks promising to you here's how I'm thinking of doing it. Use pcrs to replace parts in the hostname and use the result as the target address. Below is one way of doing it:

table foo {
    ^foo\.example\.com$ s/foo/baz/  # Replace foo in the hostname with baz. 
}

Once we have the substituted hostname use it for the target connection. A substitution command string can be distinguished from other types of addresses (hostname, unix, wildcard, ipv4, ipv6) by the presence of 3 forward slashes. A substitution command can have a port too, say s/foo/baz/:port

What do you think?

[RaitoBezarius]

I'm super interested into this feature.

I am trying to have an automatic IPv4 to IPv6 proxy which proxies *.p.example.com to *.v6.example.com automatically. I could just list explicitly all *, but that would be awesome to support such usecases.

If it's not too complicated, I can even hack a patch.