[Mark.Andrews at nominum.com]

> 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.

	Well you haven't tried to write a caching nameserver and
	had to deal with all the crap out there.  The cost of
	keeping the DNS working has shifted from those vendors that
	built the crap to those vendors that are supporting the
	clients.  They have to workaround all the mis-implementations.

	It's about time we added "protocol-conformance strict" to named
	and fail every query / response that was not strictly conformant.
	That we don't assume that the server we are quering can't handle
	EDNS because it refuses to answer a query with EDNS.  If you were
	103[45] conformant then you will answer these queries either by
	ignoring the EDNS RR and answering the query or by sending back
	a FORMERR.

	Mark

> 
> 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.
> 
> 
> 
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com