Re: Transparent vs. Non-transparent AGs/SPFs/whatever

["Ryan Russell" <ryanr () sybase com>]

> 1) AG is the sole path to the "big bad Internet"
> 2) Primary DNS resolvers are located on the same subnet as client
machines.

Why same subnet?  Do you mean just "inside" ?

> 3) Primary DNS resolvers forward DNS resolution to AG, when they're
confused.

The only contain a table of "inside" hosts, yes?

> 4) AG has X number of IP addresses/virtual interfaces assigned to it and
> configured.
> 5) I've mostly been thinking in terms of outbound access, inbound
shouldn't be
> that
> much different, though.

> Straw-man:
> 1) Client.local.goodguy.com requests an http connection to
www.somesite.com
> 1A) resolve www.somesite.com via dns.local.goodguy.com
> 1B) dns.local.goodguy.com can't resolve it, so it gets forwarded to
> dns.ag.goodguy.com
> 1C) dns.ag.goodguy.com realizes that the request came from an internal
address
> and:
> 1C1) reconfigures an available virtual interface
> 1C2) responds with this newly configured address instead of the A RR for
> www.somesite.com
> 1C3) keeps a state table of requests and responses
> 2) client.local.goodguy.com connects to the A RR that it got back via
recursive
> DNS.
> 2A) ag.goodguy.com looks at the IP address/subnet that the request came
from,
> 2B) and checks it's state table
> 2C) and then figures out which external host it should act as a proxy to
and
> proxies.

This sounds like a really clever hack.  It could rather neatly solve the
problem of
the AG not being transparent from it's point-of-view.  If you're hadning
out a
unique inside IP address per DNS name, so it can keep track of the real
destination IP
address, it think this is workable.

Unfortunatly, it doesn't help my question.  There are two side-effects of
an AG
being not transparent, and I didn't break these out very well in my
original note.
One is that your client has to do something special in terms of delivering
the packet
to the AG (i.e. that will be the destination IP address of the packet.)
You've got a potentially
nice solution for that.

The second is that the client program has the option to inform the AG what
proxy it's
speaking, and to what port on the final machine.  You browser could talk to
the AG
and say "I want HTTP at www.sun.com at port 80."  I don't imagine all proxy
clients do
this, some also probably just work off of port number.  But, the advantage
here is
that the client can pick a protocol independent of port number, i.e. it
could ask for
HTTP on port 23.

                              Ryan