> Doesn't this assume that the smart DNS server knows which of these
> protocols is being requested for each address, so that it knows which
> proxy to start up on the socket it created? Or am I missing something?
> yes, or it requires a kernel with a preemptive icmp socket.
> Sorry, I didn't make my question obvious. How does the DNS
> server know if a request for the name foo.bar.com is for
> FTP, telnet, finger, or whatever? I assume it could tell
> SMTP by an MX request, but what about the others?
There's a socket you can open in modern BSD kernels that tells you about
all the ICMP errors received or generated by the local host. If you do
a little bit of kernel work you can make this socket preemptive, that is,
arrange for it to be the endpoint of locally generated events rather than
merely a notification that such were sent. When one is about to be sent,
you can see if it's for an address you're proxying for, and if it is you
open a listener for the appropriate port and tell the kernel to retry;
otherwise you send the ICMP out so the remote connectee hears about it.
Naturally you need source code for this. Linux, BSD/OS, FreeBSD, NetBSD
all provide it. Solaris, Digital UNIX, HP-UX, and so on do not. And you
will need some expertise, which you can grow locally or buy from outside.
If you don't have the expertise to do it, you probably want to buy the
whole technology suite from someone else, such as our next contestant,
who works for "Network Translation Inc.":
> Assume that the name server is smart enough to answer "creatively" when
> asked certain questions by internal hosts about external hosts. [...]
> This is generally referred to as DNS spoofing not network address
> translation. DNS spoofing does save many people a lot of socks and proxy
> admin work, but it is not true address translation.
In the case of FTP, I feel that DNS spoofing is better than NAT. For that
matter, any protocol which encodes and encapsulates endpoint addresses
should be spoofed rather than translated -- that's my story, and I'm
sticking to it; your mileage may vary, void where prohibited, and please
don't expect me to argue with you about it. You're right that it's not NAT
and I regret that I didn't point out this subtle difference in terminology.
> Some of the assumptions, especially the tight binding between DNS replies
> and remote server identities, are unpleasantly constraining. I observe
> that this situation is only encountered by clients who don't know about
> explicit proxies, and as such, most of the user population won't have to
> suffer with it. Older and dumber clients _do_ work, though. And the
> benefits of using an RFC 1597 network are just extreme: no renumbering when
> switching carriers; multihoming for free; absolute packet-level security no
> matter who misconfigures what.
> What sort of "border gateways" keep track of relative time between
> requests for external DNS info and connection attempts to external sites?
I must be really slow today, I thought I was just describing the sort of
"border gateway" that keeps track of the relative time between requests
for external DNS info and connection attempts to external sites. As far
as I know there's no shrinkwrapped product that does this -- today.
> What's an "explicit proxy"?
Something like socks, or the TIS ftp-gw, or a proxy httpd. Anything that
requires the client to act differently when speaking to it is an "explicit"
proxy. Anything that requires no changes, awareness or context in the client
is an "implicit" proxy. "Implicit" is better overall, since you can't always
change the client. "Explicit" is better as a point solution where you have
control over all aspects of the design and you want to avoid any added costs
from spoofing (sometimes an implicit proxy has to maintain invariants that
don't matter in every connection, and this can cost you in performance.)
I had no idea that this discussion would go on so long. As before, I am not
on the firewalls mailing list, so if you want me to see your reply, CC me.
La Honda, CA "Illegitimi non carborundum."
pacbell!vixie!paul (dont let the bastards grind you down)