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-us...@lists.isc.org>,
Kevin Darcy<k...@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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
