<!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="#ffffcc" text="#000000">
<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 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 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>
<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>
<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>
<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? Let each part of the system do the job it was
put there to do and not try to do what it does not really understand
how to do in the long run. Otherwise you ask for trouble for your
successor.<br>
<br>
<blockquote cite="mid:4BB8B33B.4070906@chrysler.com" type="cite"><br>
I realize that such a default setting may not be very popular. A lot
of, er, unsophisticated customers for such devices may not realize or
understand the default setting and then may have a tough time
understanding why they have difficulty serving DNS to certain clients.
But this is a matter of notification/documentation and education. The
manual should have in big red letters "IF YOU WANT TO SUPPORT CERTAIN
LEGACY CLIENTS THAT DO NOT CONFORM TO BEST CURRENT SECURITY PRACTICES,
YOU NEED TO CHANGE THE DEFAULT SETTING". At least then, the customer is
made aware of the insecurity that they are enabling by changing the
setting. This may also be a factor if there is ever any question about
legal liability in the case of a security event.
<br>
<br>
<blockquote type="cite">I suspect this is actually a bug, but the
vendor is using the security
<br>
value of it as an excuse to lower its priority.
<br>
</blockquote>
That may also be true, if I were dealing with the vendor I'd point out
that if it is a deliberate security design, it should only be a default
and there *must* be a way to turn it off. I can think of lots of
internal environments where the clients and servers, and their
interaction is considered secure, but there is a re-use -- or apparent
re-use -- of source ports, and in those particular cases the
load-balancer shouldn't be refusing service. If there is no way to turn
off this "security feature", then it should be possible to embarrass
the vendor into admitting that it's really a bug rather than a
designed-in feature.
<br>
<br>
- Kevin
<br>
<br>
<br>
_______________________________________________
<br>
bind-users mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
</pre>
</body>
</html>