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.
% % 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.
> 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.
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.
> 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.
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" <bmann...@ISI.EDU> wrote in message
> % > % 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.
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.
"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)
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" <bmann...@ISI.EDU> wrote in message % news:9q1tp8$mrk@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 % > % > % % %
In article <9q22d1$...@pub3.rc.vix.com>, Michael Kjorling <mich...@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.
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 > 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
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 j...@center.osis.gov - Joseph S. D. Yao OSIS Center Systems Support EMT-B ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
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" <bmann...@ISI.EDU> wrote in message
> 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" <bmann...@ISI.EDU> wrote in message > % news:9q1tp8$mrk@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 > % > > % > > % > % > %
> 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.
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.
> > 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" <bmann...@ISI.EDU> wrote in message > > % news:9q1tp8$mrk@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,
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" <bmann...@ISI.EDU> wrote in message % news:9q23h6$nrh@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" <bmann...@ISI.EDU> wrote in message % > % news:9q1tp8$mrk@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 % > % > % % %
> 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.
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.know...@skynet.be> wrote in message
> 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.
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.
> > 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... 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 terminated.
>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.
> >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...
>those who know me have no need of my name wrote: >> <9q4bp5$...@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.
