Possible System Compromise

Kevin Darcy kcd at daimlerchrysler.com
Mon Feb 12 16:31:13 UTC 2001


schulz at adi.com wrote:

> UDP is a horribly insecure protocol and you do not want to let
> it through to random high numbered ports.  TCP on the other hand has the
> concept of an established connection.  It is fairly safe to allow all
> established incomming data through the router.  (I really wish that
> BIND did not use UDP at all).

Surely you can't be serious. TCP is a horribly *wasteful* protocol for
message-oriented transactions where absolute reliability and guaranteed
ordering are not hard prerequisites.

I think you're blaming BIND (and by extension the RFC's BIND follows, which
specify UDP) for the specific deficiencies of particular firewall/router
products. Sure, TCP "has the concept of an established connection", but
router/firewall products can only really tell who *initiated* that
connection by looking at the SYN/ACK bits of the original connection-setup
packets. If they can do that, they _should_ be able to look at the bits of a
DNS UDP packet to see if it's a query or a response. If your product can't
do that, then you should demand such a feature from your router/firewall
vendor (or your money back).

Of course, if you use an application-proxy firewall architecture, with
nameservers running on the firewalls themselves, then the whole issue
becomes moot, since then nothing is going *through* the firewall _per_se_
and you can put whatever access controls you want in the firewall
nameservers' configurations, which of course are perfectly capable of
distinguishing incoming from outgoing queries versus responses. So I suppose
it could also be said that you're blaming BIND and/or the RFC's for an
inherent disadvantage of the firewall architecture you have chosen.


- Kevin



More information about the bind-users mailing list