Same source port queries dropped by ServerIron load balancer
Kevin Darcy
kcd at chrysler.com
Mon Apr 5 22:08:44 UTC 2010
On 4/4/2010 2:24 PM, Sten Carlsen wrote:
>
>
> On 04/04/10 17:41, Kevin Darcy wrote:
>> On 4/1/2010 9:19 PM, Barry Margolin wrote:
>>> In article<mailman.1048.1270148466.21153.bind-users at lists.isc.org>,
>>> Kevin Darcy<kcd at chrysler.com> wrote:
>>>
>>>> Re-use of source ports for DNS queries is a bad security practice. I
>>>> cast my vote in favor of penalizing it, in the default
>>>> configuration of
>>>> any device that responds to DNS requests.
>>> It's really not the job of a load balancer or server to force
>>> clients to
>>> use good security practices.
>> 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.
>>
>> 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.
> 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.
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?
>
> 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.
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.
>
> 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.
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.
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.
>
> 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?
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.
- Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100405/c61f87c4/attachment.html>
More information about the bind-users
mailing list