Same source port queries dropped by ServerIron load balancer

[Kevin Darcy]

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>