tcp/udp, clarification please
Eoin Miller
more secure, my question is this, are there any types of OS's that require
the resolving server to use TCP? or are there any other downsides to not
letting TCP traffic through the firewall.
Reguards,
Eoin Miller
Bill Manning
%
% basically its my understanding that using BIND with only UDP can be a bit
% more secure, my question is this, are there any types of OS's that require
% the resolving server to use TCP? or are there any other downsides to not
% letting TCP traffic through the firewall.
%
% Reguards,
% Eoin Miller
%
neither is more secure than the other. UDP works for small packets and
simple queries. Complex RRsets and big packets (zone transfers, dynamic
updates, SIG/CERT RRs, A6 chaining, multiple AAAAs etc.) exceed UDP
packet limits and will "failover" to using TCP.
--
--bill
Simon Waters
DNS uses both UDP and TCP.
Any attempt to implement a DNS service without allowing both is
clearly in breach of the RFC's, and likely to cause incorrect
behaviour.
A common mistake is to block TCP, I've made it myself in earlier
times, but it is wrong to do so.
Cricket Liu gave some examples of resolvers that ONLY use TCP in
this list recently, although they were a pretty esoteric bunch,
and have probably been long since retired.
ar...@carlander.ac
TCP is used normally and UDP is used if TCP fails, so disallowing TCP at
your firewall would cause delays and retransmissions.
-Arvid
"Eoin Miller" <u...@ftc.gov> wrote in message
news:9q1sqc$m...@pub3.rc.vix.com...
Eoin Miller
still work, so this would cut down the functionality that the rest of the
world does not need correct? the world needs only the resolving portion, my
setup is very simple and minimal, the zone transfers happen behind the
firewall ect ect
"Bill Manning" <bman...@ISI.EDU> wrote in message
news:9q1tp8$m...@pub3.rc.vix.com...
Michael Kjorling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wrong. Any sane DNS implementation will first try using UDP, and (in
case the response is truncated) MAY retry the query using TCP. I
belive the RFCs say MAY and not MUST. Can't remember in what RFC the
meaning of these words were codified, but it is there somewhere.
Zone transfers always work over TCP, though. There may be other parts
of DNS which uses TCP by default, and as someone (was it Kevin?)
pointed out a while back some ancient platforms don't have UDP in
their IP stack so they are stuck with TCP.
I can't belive so many people want to "secure" their DNS servers by
only allowing UDP... it causes major trouble and at the _very_ least
serious delays if the response is too big to fit into a single UDP
packet and TCP is blocked.
Michael Kjörling
On Oct 10 2001 17:40 +0100, ar...@carlander.ac wrote:
> Eoin,
>
> TCP is used normally and UDP is used if TCP fails, so disallowing TCP at
> your firewall would cause delays and retransmissions.
>
> -Arvid
- --
Michael Kjörling -- Programmer/Network administrator ^..^
PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e \/
Internet: mic...@kjorling.com -- FidoNet: 2:204/254.4
"There is something to be said about not trying to be glamorous
and popular and cool. Just be real -- and life will be real."
(Joyce Sequichie Hifler, September 13 2001)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Public key is at http://michael.kjorling.com/contact/pgp.html
iD8DBQE7xIqLKqN7/Ypw4z4RAqD6AKDXdamWeosS53qlc5JaiLryXWMZ7QCg+RlG
7zpHIfRLNiCuMDxt4orUnE4=
=CcU5
-----END PGP SIGNATURE-----
Bill Manning
Some subset of DNS would work. Others would fail in odd ways.
You can not presume that even with "minimal" setups that client
requests won't exceed UDP packet size. Cutting off TCP will
prevent your organization from adopting better security tools,
tools that are known to provide integrity checks on the data.
Even things which may not be an improvement but are adopted
"just because", things like Active Directory & GSSTSIG from
a popular vendor push DNS into TCP because of the size of the
response.
Simple UDP is much more prone to data integrity corruption than
data that uses TCP. But your zones, your choice. Your support
costs (opex) will go up if you cut TCP as you will have to deal
with odd failures The apparent robustness of your sites will
decrease for both internal and external clients.
%
% So someone couldnt do a zone transfer if i left only UDP open and DNS would
% still work, so this would cut down the functionality that the rest of the
% world does not need correct? the world needs only the resolving portion, my
% setup is very simple and minimal, the zone transfers happen behind the
% firewall ect ect
%
%
% "Bill Manning" <bman...@ISI.EDU> wrote in message
% news:9q1tp8$m...@pub3.rc.vix.com...
% >
% > %
% > % basically its my understanding that using BIND with only UDP can be a
% bit
% > % more secure, my question is this, are there any types of OS's that
% require
% > % the resolving server to use TCP? or are there any other downsides to not
% > % letting TCP traffic through the firewall.
% > %
% > % Reguards,
% > % Eoin Miller
% > %
% >
% > neither is more secure than the other. UDP works for small packets and
% > simple queries. Complex RRsets and big packets (zone transfers, dynamic
% > updates, SIG/CERT RRs, A6 chaining, multiple AAAAs etc.) exceed UDP
% > packet limits and will "failover" to using TCP.
% >
% > --
% > --bill
% >
% >
%
%
%
--
--bill
Barry Margolin
Michael Kjorling <mic...@kjorling.com> wrote:
>I can't belive so many people want to "secure" their DNS servers by
>only allowing UDP... it causes major trouble and at the _very_ least
Believe it.
>serious delays if the response is too big to fit into a single UDP
>packet and TCP is blocked.
It's very unlikely that the sites that block UDP would ever generate a
response that exceeds 500 bytes.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Joseph S D Yao
On Wed, Oct 10, 2001 at 12:55:51PM -0400, Eoin Miller wrote:
> So someone couldnt do a zone transfer if i left only UDP open and DNS would
If this is what you want to do, then current versions of BIND 8 and 9
give you the capability to selectively allow zone transfers from as
narrow or wide a range as you desire.
DNS would NOT "still work" - at least, not particularly reliably - if
you opened UDP and closed TCP.
Do not seek to pick fruit by cutting the tree's trunk.
Why not have a DNS proxy ['named' can serve as such] on your firewall?
That would be even better than opening a UDP hole through your firewall.
--
Joe Yao js...@center.osis.gov - Joseph S. D. Yao
OSIS Center Systems Support EMT-B
-----------------------------------------------------------------------
This message is not an official statement of OSIS Center policies.
Eoin Miller
security tools? my zone transfers would still be going over TCP because i
have a firewall/DMZ setup, and behind the firewall TCP is allowed to
transfer between the boxes, but to the outside world only UDP is accessable,
i fail to see how if i remove the protocol that is required to do anything
but very simple level services, just minimal host resolution is all that is
necessary for the outside world to be able to access, the internal LAN and
the DMZ still would have access to all the normal functionality of BIND. All
i am asking is name resolution possible with UDP, and if that is all i need
to let the rest of the world use these servers for, and by not even allowing
requests on the TCP protocol to get past the firewall, that eliminates just
about all of the hacks in the book from my understanding.
"Bill Manning" <bman...@ISI.EDU> wrote in message
news:9q23h6$n...@pub3.rc.vix.com...
Brad Knowles
At 10:04 AM -0400 2001/10/11, Eoin Miller wrote:
> how would having no TCP access to my DNS servers prevent adoption of better
> security tools?
Because advanced DNS security measures like TSIG and DNSSEC
make the packets so large that they are almost certainly guaranteed
to be too big to fit into a single UDP packet?
> my zone transfers would still be going over TCP because i
> have a firewall/DMZ setup, and behind the firewall TCP is allowed to
> transfer between the boxes, but to the outside world only UDP is accessable,
This is fundamentally the wrong way to do it. Allow both TCP
and UDP through to your nameserver, and then use the mechanisms built
into the nameserver software (e.g., BIND) to restrict who is/is not
allowed to perform a zone transfer.
If you choose to configure your nameserver in any other
fashion, you're welcome to support the thing entirely and completely
on your own, but please don't ask anyone else in the world for any
help.
And once again, I must ask you to stop lying about your
return e-mail address, and causing e-mail replies to be sent back to
the US Federal Trade Commission. If anything, by this action, you
are as bad as (or worse) a criminal than all the spammers out there.
If you continue to participate in this illegal activity, then
I will be forced to contact the appropriate people at RCN and begin
proceedings to have your account terminated.
--
Brad Knowles, <brad.k...@skynet.be>
H4sICIFgXzsCA2RtYS1zaWcAPVHLbsMwDDvXX0H0kkvbfxiwVw8FCmzAzqqj1F4dy7CdBfn7
Kc6wmyGRFEnvvxiWQoCvqI7RSWTcfGXQNqCUAnfIU+AT8OZ/GCNjRVlH0bKpguJkxiITZqes
MxwpSucyDJzXxQEUe/ihgXqJXUXwD9ajB6NHonLmNrUSK9nacHQnH097szO74xFXqtlbT3il
wMsBz5cnfCR5cEmci0Rj9u/jqBbPeES1I4PeFBXPUIT1XDSOuutFXylzrQvGyboWstCoQZyP
dxX4dLx0eauFe1x9puhoi0Ao1omEJo+BZ6XLVNaVpWiKekxN0VK2VMpmAy+Bk7ZV4SO+p1L/
uErNRS/qH2iFU+iNOtbcmVt9N16lfF7tLv9FXNj8AiyNcOi1AQAA
Brian Salomaki
The problem security-wise occurs when you block TCP packets, and then assume
that you're completely safe. However, as people have tried to explain, if
you do block TCP packets, then your nameserver is in violation of the DNS
specifications. BIND will only send out a small amount of data in a UDP
packet. If that response is truncated, then the resolver will request again,
using TCP so that it can receive all of the information.
Bottom line: don't block TCP traffic over port 53.
On Thursday 11 October 2001 10:04 am, Eoin Miller wrote:
> how would having no TCP access to my DNS servers prevent adoption of better
> security tools? my zone transfers would still be going over TCP because i
> have a firewall/DMZ setup, and behind the firewall TCP is allowed to
> transfer between the boxes, but to the outside world only UDP is
> accessable, i fail to see how if i remove the protocol that is required to
> do anything but very simple level services, just minimal host resolution is
> all that is necessary for the outside world to be able to access, the
> internal LAN and the DMZ still would have access to all the normal
> functionality of BIND. All i am asking is name resolution possible with
> UDP, and if that is all i need to let the rest of the world use these
> servers for, and by not even allowing requests on the TCP protocol to get
> past the firewall, that eliminates just about all of the hacks in the book
> from my understanding.
>
> "Bill Manning" <bman...@ISI.EDU> wrote in message
> news:9q23h6$n...@pub3.rc.vix.com...
--
Brian Salomaki
Gambit Design Internet Services
110 E. State St., Suite 18, Kennett Square, PA 19348
DNSbox: http://gambitdesign.com
Bill Manning
Security (actually authentication and integrity) come with the use of
new RR types. Specifically SIG/KEY/CERT. With reasonable salts (128bits
or larger) these RRs will push/exceed IPv4 UDP packet size limits.
Complex RRsets will also push over the limits of IPv4 UDP. This occurs
in many cases, not the least of which is when many RRs are listed for
a single lable. (25 A RRs for a ftc.gov, for example)
Again, this is your delegation and you get to do what you want with it.
The biggest problem is your assertion that TCP access to the DNS is how
most hacks to the DNS occur. I, for one, would be interested in how you
reached this conclusion and any data you have to back this belief. Most
of the attack vectors to the DNS, that I am aware of, are exploitable
via UDP as well as TCP.
It is true that some haqers gain "intel" on the scope of the intended
target by use of zone transfers. If this is the main perceived threat,
it is easier to restrict transfers via the "allow-transfer" clause that
kill TCP access, at least for most server admins.
% how would having no TCP access to my DNS servers prevent adoption of better
% security tools? my zone transfers would still be going over TCP because i
% have a firewall/DMZ setup, and behind the firewall TCP is allowed to
% transfer between the boxes, but to the outside world only UDP is accessable,
% i fail to see how if i remove the protocol that is required to do anything
% but very simple level services, just minimal host resolution is all that is
% necessary for the outside world to be able to access, the internal LAN and
% the DMZ still would have access to all the normal functionality of BIND. All
% i am asking is name resolution possible with UDP, and if that is all i need
% to let the rest of the world use these servers for, and by not even allowing
% requests on the TCP protocol to get past the firewall, that eliminates just
% about all of the hacks in the book from my understanding.
%
% "Bill Manning" <bman...@ISI.EDU> wrote in message
% news:9q23h6$n...@pub3.rc.vix.com...
% >
% >
% > Some subset of DNS would work. Others would fail in odd ways.
% > You can not presume that even with "minimal" setups that client
% > requests won't exceed UDP packet size. Cutting off TCP will
% > prevent your organization from adopting better security tools,
% > tools that are known to provide integrity checks on the data.
% > Even things which may not be an improvement but are adopted
% > "just because", things like Active Directory & GSSTSIG from
% > a popular vendor push DNS into TCP because of the size of the
% > response.
% >
% > Simple UDP is much more prone to data integrity corruption than
% > data that uses TCP. But your zones, your choice. Your support
% > costs (opex) will go up if you cut TCP as you will have to deal
% > with odd failures The apparent robustness of your sites will
% > decrease for both internal and external clients.
% >
% >
% > %
% > % So someone couldnt do a zone transfer if i left only UDP open and DNS
% would
% > % still work, so this would cut down the functionality that the rest of
% the
% > % world does not need correct? the world needs only the resolving portion,
% my
% > % setup is very simple and minimal, the zone transfers happen behind the
% > % firewall ect ect
% > %
% > %
% > % "Bill Manning" <bman...@ISI.EDU> wrote in message
% > % news:9q1tp8$m...@pub3.rc.vix.com...
% > % >
% > % > %
% > % > % basically its my understanding that using BIND with only UDP can be
% a
% > % bit
% > % > % more secure, my question is this, are there any types of OS's that
% > % require
% > % > % the resolving server to use TCP? or are there any other downsides to
% not
% > % > % letting TCP traffic through the firewall.
% > % > %
% > % > % Reguards,
% > % > % Eoin Miller
% > % > %
% > % >
% > % > neither is more secure than the other. UDP works for small packets
% and
% > % > simple queries. Complex RRsets and big packets (zone transfers,
% dynamic
% > % > updates, SIG/CERT RRs, A6 chaining, multiple AAAAs etc.) exceed UDP
% > % > packet limits and will "failover" to using TCP.
% > % >
% > % > --
% > % > --bill
% > % >
% > % >
% > %
% > %
% > %
% >
Brad Knowles
At 8:23 AM -0700 2001/10/11, Bill Manning wrote:
> The biggest problem is your assertion that TCP access to the DNS is how
> most hacks to the DNS occur. I, for one, would be interested in how you
> reached this conclusion and any data you have to back this belief. Most
> of the attack vectors to the DNS, that I am aware of, are exploitable
> via UDP as well as TCP.
Actually, the more I think about it, the more I think that
most DNS-related attacks probably come through UDP and not TCP. It's
much harder to spoof a "reply" as coming from a particular host with
TCP, whereas it's trivially easy to do with UDP. This means that
cache-poisoning attacks are harder to perform over TCP and much
easier over UDP. Most other DNS-related attacks (including DoS
attacks) that I know of also make use of UDP and not TCP.
Eoin Miller
the rest of the world is blocked from using anything other than UDP, the DNS
servers can use TSIG no problem, TCP would ONLY INCOMING TCP requests would
be blocked at the firewall, on the DMZ the TCP traffic would flow freely
back and forth between NS1 and NS2.
"Brad Knowles" <brad.k...@skynet.be> wrote in message
news:9q4d61$6...@pub3.rc.vix.com...
Brian Salomaki
TCP traffice *needs* to go through the firewall to the internet, not just to
the other nameserver. If a client/resolver anywhere on the internet queries
your server, and gets a truncated response, then it will retry the query
using TCP. If TCP isn't enabled, then that client will not be able to
properly resolve names hosted by your server. In practice, if you're doing
very small-scale DNS, then you may not run into this issue, but if you are
intent on blocking TCP traffic, you're not going to find people particularly
eager to help you if you ever have problems. Our stance is that TCP is
enabled, period. There's no good reason to disable it, but there are many
good reasons to leave it enabled. The most we can do is tell you to enable
TCP, and we've already done that more times than we probably should have. If
you don't enable it, then I suppose that's your problem; we're not going to
break into your firewall and try to open up TCP traffic on port 53.
On Thursday 11 October 2001 11:43 am, Eoin Miller wrote:
> brad... the DNS servers can talk to each other using TCP no problem, *ONLY*
> the rest of the world is blocked from using anything other than UDP, the
> DNS servers can use TSIG no problem, TCP would ONLY INCOMING TCP requests
> would be blocked at the firewall, on the DMZ the TCP traffic would flow
> freely back and forth between NS1 and NS2.
>
>
> "Brad Knowles" <brad.k...@skynet.be> wrote in message
> news:9q4d61$6...@pub3.rc.vix.com...
>
--
Brad Knowles
At 11:43 AM -0400 2001/10/11, Eoin Miller wrote:
> brad... the DNS servers can talk to each other using TCP no problem, *ONLY*
> the rest of the world is blocked from using anything other than UDP, the DNS
> servers can use TSIG no problem, TCP would ONLY INCOMING TCP requests would
> be blocked at the firewall, on the DMZ the TCP traffic would flow freely
> back and forth between NS1 and NS2.
But DNSSEC is something done between your servers and the
rest of the world, so blocking TCP still breaks that. An it probably
wouldn't be too much fun with IPv6 (which makes addresses much, much
longer), either.
However, as I previously pointed out, the real security issue
with DNS is from *UDP* packets, not *TCP*. Therefore, if you want to
make your nameserver truly secure, you will turn off all UDP packets
at your firewall to your nameserver.
Please make sure that you do this ASAP, so as to protect
yourself against cache poisoning, DoS, and other spoofing attacks.
BTW, I am now filing a complaint with RCN to get your account
those who know me have no need of my name
<9q4bp5$6...@pub3.rc.vix.com> divulged:
>how would having no TCP access to my DNS servers prevent adoption of better
>security tools?
you've already been told, but i'll say it differently, in case it helps ...
if you want others to be able to trust your server's responses you might
want to deploy gsstsig. unfortunately those responses usually exceed udp
datagram payload constraints, hence a tcp connection would be needed for
the client to obtain the entire response, and since you've blocked tcp that
isn't possible, so the clients won't be able to resolve those names.
also, as has been mentioned, there are clients that exist which only use
tcp. these clients will not be able to resolve any names.
so, if you know that you will not deploy large rrsets (e.g., signed), and
you are willing to accept occasional client failures, then go right ahead.
just remember that the occasion might be your ceo making a pitch at a large
trade show.
--
okay, have a sig then
Kevin Darcy
those who know me have no need of my name wrote:
> <9q4bp5$6...@pub3.rc.vix.com> divulged:
>
> >how would having no TCP access to my DNS servers prevent adoption of better
> >security tools?
>
> you've already been told, but i'll say it differently, in case it helps ...
> if you want others to be able to trust your server's responses you might
> want to deploy gsstsig.
Hmmm... Did you really mean "gsstsig" here? Or did you mean DNSSEC generically?
IMHO GSS-TSIG is *not* the future of DNS security, just an annoying dead-end...
- Kevin
those who know me have no need of my name
<9qi8bd$g...@pub3.rc.vix.com> divulged:
>> >how would having no TCP access to my DNS servers prevent adoption of better
>> >security tools?
>>
>> you've already been told, but i'll say it differently, in case it helps ...
>> if you want others to be able to trust your server's responses you might
>> want to deploy gsstsig.
>
>Hmmm... Did you really mean "gsstsig" here? Or did you mean DNSSEC
>generically?
i was shooting for anything that might convince the original poster of the
potential downside, without making the response so generic that it would
feel "unreal" to him. which is also why i didn't bother ipv6, since it is
still pretty tenuous for most people. (and had already been well described
anyway.)
however, you certainly are correct. any form of cryptographic process
applied to the results quickly increases the likelihood that it will
overflow the upper limit of using udp.