One Domain; Multiple IPs.

Marc.Thach at radianz.com Marc.Thach at radianz.com
Thu Jul 19 14:06:49 UTC 2001



Brad
I'm just another nutter replying to my own postings, but getting the
subject right this time.
I has a quick look at www.vegan.net/lb which you mentioned  in another post
and it kind of explained TCP triangulation (I find that hard to spell, let
alone implement).  It looks to me that it is only a partial solution, maybe
good for small unidirectional flows but for persistent connections or large
symmetric flows then the one-way latency is going to dominate.  It also
looks like it requires source address spoofing, is that right?
rgds
Marc TXK



                                                                                                                   
                    Marc.Thach at radi                                                                                
                    anz.com                To:     Mark.Andrews at nominum.com, Brad Knowles <brad.knowles at skynet.be> 
                    Sent by:               cc:     bind-users at isc.org                                              
                    bind-users-boun        Subject:     (no subject)                                               
                    ce at isc.org                                                                                     
                                                                                                                   
                                                                                                                   
                    19/07/2001                                                                                     
                    12:32                                                                                          
                                                                                                                   
                                                                                                                   





Brad has (in various mails) written:

> Use TCP triangulation.  Have the SYN packet come into a
> particular device, have that device make a decision as to where to
> cause that connection to be set up, then it generates an outgoing SYN
> packet to that back-end machine, which then proceeds to finish
> setting up the TCP connection with the client that generated the
> original SYN.

Can you explain this technique more please? references maybe.

> True enough, but another part of my complaint is the fact that
> they are used to abuse and mis-use the DNS as a mechanism to solve
> problems that are best solved with other techniques.

> I think you're losing the forest for the trees.  Yes, some sort
> of solution needs to be had for the distribution/load-balancing
> issues, but the DNS is a particularly poorly suited tool to use for
> this purpose.

> If anything, I am the one advocating a "new technology", and you
> are the one actively resisting this suggestion by suggesting that we
> continue to use the same technology that we've had in stasis for many
> years.

You are right that use of DNS for load-balancing is a misuse of the DNS
tool.  Yes, there may be better ways of achieving the technical objective.
But my view of the forest is this:
A server owner wants the fastest and cheapest service to the clients.
He/she therefore wishes to minimise global bandwidth costs and latency
(amongst other things).
He/she doesn't know or care one iota about Internet standards.
He/she most definitely wishes to minimise design and operational costs.
DD (which is the instance of the technique that I'm familiar with) is
relatively cheap.
It's well established therefore it's what his/her management team has heard
of, "nearest available server? that's DD isn't it, we'll get the DNS guys
onto it".
It's vendor-supported (not all decisions are based on logic)
It is physically localised in the network, at it's simplest only a single
extra box is required.
It does what he/she thinks is required.

When a new technology replaces it for business reasons, then it will die
naturally.  I won't mourn its passing but until then I'll use it.

> The more I think about it, the more I believe that this technique
> is probably actually a key player in the kinds of network routing and
> congestion problems that have plagued the 'net within the last few
> years.

I' love to see your reasoned justification for that one.

Mark wrote:
> Client will requests lots of things AAAA records and A6
> are starting to be as common a A requests.  Also questions
> with EDNS should be answered even if it is just FORMERR,
> some of these boxes don't do that.  MX queries will also
> be common and hopefully SRV queries soon.

> Saying that other record types should not be requested is
> just plain wrong.  It is thinking like this that causes
> some of the abominations that are out there pretending to
> be nameservers.

> For which there is no good reason and causes operational
> problems from time to time.  When will nameserver vendors
> learn that DNS/TCP really is not optional.  That people
> will configure servers such that fallback to TCP will be
> required.

I've communed for several years with a pretend nameserver and complained
and moaned about it, but it functioned and adequately supported services
that kept customers happy and generated revenue.  It only did A records.
It only did UDP.  Unless you can demonstrate specific harm (apart from
obviously slowing the uptake of alternatives or of other protocol elements
which cause conflicts) to services outside of the actual domain using the
technique  then I can't concede the point.

rgds
Marc TXK
________________________________________________________________________
The views expressed are personal and do not necessarily reflect those of
the organisation providing the mail address from which this message was
sent




The contents of this e-mail and any attachments contain information that
may be confidential.  Unless you are the named addressee (or authorized to
receive for the named addressee) you may not read, copy, distribute,
disclose or otherwise use this information for any purpose.  If you have
received this transmission in error, please notify the sender immediately
by reply e-mail and then delete this message from your system.  While we
make every effort to keep our network free from viruses, you do need to
check this e-mail (and any attachments) for viruses, as we take no
responsibility for any virus transferred by this e-mail.












More information about the bind-users mailing list