<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 4/4/2010 2:24 PM, Sten Carlsen wrote:
<blockquote cite="mid:4BB8D95B.1020706@s-carlsen.dk" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
<br>
<br>
On 04/04/10 17:41, Kevin Darcy wrote:
<blockquote cite="mid:4BB8B33B.4070906@chrysler.com" type="cite">On
4/1/2010 9:19 PM, Barry Margolin wrote: <br>
<blockquote type="cite">In
article<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:mailman.1048.1270148466.21153.bind-users@lists.isc.org"><mailman.1048.1270148466.21153.bind-users@lists.isc.org></a>,
<br>
Kevin Darcy<a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:kcd@chrysler.com"><kcd@chrysler.com></a> wrote: <br>
<br>
<blockquote type="cite">Re-use of source ports for DNS queries is
a
bad security practice. I <br>
cast my vote in favor of penalizing it, in the default configuration of
<br>
any device that responds to DNS requests. <br>
</blockquote>
It's really not the job of a load balancer or server to force clients
to <br>
use good security practices. <br>
</blockquote>
Trouble is, when everyone carves out their little area of
responsibility such that enforcing good security practices is "not my
job, man", then very few things enforce security practices, and
ultimately they don't get enforced at all. <br>
<br>
Certainly a load-balancer can legitimately refuse to serve queries that
are suspect, can it not? E.g. that are malformed in particular ways
that indicate hostile intent. So, where in the spectrum of
"suspectness" can we draw the line and say, everything on that side, I
trust to answer, and everything on the other side of the line, I don't?
I think a client that re-uses source ports is untrustworthy. Therefore
I think it's a reasonable default to decline to service queries from
such clients. <br>
</blockquote>
The question I saw being raised was not if such queries wer trustworthy
or not; but whether it is the job of a load balancer to judge the inner
workings of an application protocol.<br>
</blockquote>
Sorry, pet peeve, but DNS is an "application protocol" like paddles on
a rowboat are merely ornamental trappings. Sure, one _could_
theoretically get along with it/them, but how realistic is that? In
practical terms, DNS is a core networking protocol, necessary for most
process-to-process communcation at the Transport Layer and above.
That's how it's treated by support organizations, too: does one ever
see DNS lumped in with "applications" from a support standpoint?<br>
<br>
<blockquote cite="mid:4BB8D95B.1020706@s-carlsen.dk" type="cite"><br>
I tend to agree that the load balancer should just hand the packets on
to whoever is there to answer the questions/serve the content.<br>
</blockquote>
It wasn't clear (to me, at least) from the original post
whether the load-balancer in question was just front-ending
some DNS service, or whether it was a GSLB-type load-balancer that was
actually the definitive source of the (dynamically-changing) DNS
information, front-ending some other protocol(s), e.g. HTTP/HTTPS,
SMTP, LDAP. If it's a GSLB device that is the last link-in-the-chain,
then certainly it has the right to enforce whatever security policies
the owner/administrator wants. If on the other hand it's just
forwarding the query to some
back-end DNS infrastructure, and if it can provide the information
necessary for the back-end infrastructure to make a reasonable security
determination (i.e. using the client's original source port), then
fine, pass on the responsibility for enforcement. If not, then the
load-balancer needs to do the enforcement itself.<br>
<br>
<blockquote cite="mid:4BB8D95B.1020706@s-carlsen.dk" type="cite"><br>
This would be the reason we have heard so much about broken
routers/bridges/firewalls/... that will not allow EDNS packets, because
they were once suspect.<br>
</blockquote>
<br>
Routers/bridges/firewalls, etc. that should, in the normal case, be
passing packets back and forth without presuming "special" knowledge of
the DNS protocol, should be lumped together with load-balancers that
front-end a DNS infrastructure. <br>
<br>
But, again, if we're talking about a load-balancer that is a GSLB
*definitive* source of the DNS data, then it is in a different class
than "transparent" or proxying devices. It is, in effect, the *source*
of the DNS information, and shouldn't be giving out data to clients it
suspects may misuse that data or be compromised by the response.<br>
<br>
<br>
<blockquote cite="mid:4BB8D95B.1020706@s-carlsen.dk" type="cite"><br>
When DNSSEC/NSEC/... is completely implemented, who will then
reevaluate if this load balancer is in need of a change? maybe there
will be nobody to fix it? <br>
</blockquote>
I think that's part of the larger question of how all of these Stupid
DNS Tricks that people are today performing with load-balancers, CDNs,
etc. will inter-operate with DNSSEC, if at all. The Stupid DNS Tricks,
after all, do essentially amount to *lying* about DNS data, and DNSSEC
is essentially a mechanism for detecting, and presumably rejecting, DNS
lies. It's hard to get such things to co-exist.<br>
<br>
-
Kevin<br>
<br>
<br>
</body>
</html>