On Thu, 23 May 2002, Ramin Alidousti wrote:

> On Thu, May 23, 2002 at 02:56:58PM -0600, Marc Aurele La France wrote:

> > > Best of luck with the request, and I'm fascinated to know why this is
> > > considered a sensible way to run UDP....

> > One can easily run DNS this way, for load balancing, etc.

> Can you come up with a scenario for this DNS case? Do you mean that
> I send a DNS query to A and B would give me the answer?

Yes.  A is a NAT box that load balances (but doesn't hide) B, C, etc.  So,
the reply to your request to A could come from either one of B, C, etc.
And A can be something as small as a 386 because kernel-level NAT'ting
doesn't need a lot of ummph.  We've tried a similar thing with SAMBA a
few years ago, although SAMBA also involves TCP on a more regular basis,
making things a little messier.  This is handy when you're waiting for
mucky-mucks to decide on the funding for a bigger server.

> But, anyway, If you do SNAT for the outgoing UDP packets, what prevents
> you to do DNAT for the _unrelated_ incoming UDP packets? Or maybe I don't
> understand you question well?

That would generate a lot of false positives and negatives.  By INPUT
time, I don't see how I can determine whether the packet wasn't de-masq'ed
simply because its source addr/port wasn't what the outgoing packet said
it would be.  Neither can I tell if the target port was masq'ed in the
first place (this also true of a PRE-ROUTING rule).  By then, it's too
late anyway because the routing decision's already been made.  No, this
needs be done during de-masq'ing, part of PRE_ROUTING.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Computing and Network Services  |  fax:    1-780-492-1729           |
|  352 General Services Building   |  email:  [EMAIL PROTECTED]          |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 Core Team member.  ATI driver and X server internals.


Reply via email to