In the thread about ns*.worldnic.com, many people were complaining about DNS responses/queries on TCP port 53. At least one DoS mitigation box uses TCP53 to "protect" name servers. Personally I thought this was a pretty slick trick, but it appears to have caused a lot of problems. From the thread (certainly not a scientific sampling), many people seem to be filtering port 53 TCP to their name servers. Is this common? Does anyone have stats on this (roots, GTLDs, other big name server farms)? Perhaps people could send what they do personally and I can summarize for this list. (Again, not a scientific sampling method, but better than trying to read into what people imply in a long, and probably not-well-read thread.) -- TTFN, patrick P.S. Sorry to post operational content, I know how everyone hates that. =)
* Patrick W. Gilmore:
At least one DoS mitigation box uses TCP53 to "protect" name servers. Personally I thought this was a pretty slick trick, but it appears to have caused a lot of problems. From the thread (certainly not a scientific sampling), many people seem to be filtering port 53 TCP to their name servers.
"To their name servers"? I think you mean "from their caching resolvers to 53/TCP on other hosts".
Is this common?
Hopefully not. Resolvers MUST be able to make TCP connections to other name servers.
Does anyone have stats on this (roots, GTLDs, other big name server farms)?
What kind of stats? I might be able to provide some statistics about TC flag usage, but I doubt that this data is interesting.
On Tue, 26 Apr 2005, Florian Weimer wrote:
* Patrick W. Gilmore:
At least one DoS mitigation box uses TCP53 to "protect" name servers. Personally I thought this was a pretty slick trick, but it appears to have caused a lot of problems. From the thread (certainly not a scientific sampling), many people seem to be filtering port 53 TCP to their name servers.
"To their name servers"? I think you mean "from their caching resolvers to 53/TCP on other hosts".
its a both directions thing. Some folks dropped tcp/53 TO their AUTH servers to protect against AXFR's from folks not their normal secondaries. Obviously this is from before bind8+'s capability to acl. Even after I imagine that folks left the filters in place either 'because' or 'I don't run router acls' or 'laziness'....
Is this common?
Hopefully not. Resolvers MUST be able to make TCP connections to other name servers.
It seems that what might be more common is resolver code not handling the truncate request properly :( That seemed to be the majority of the problems last time we ran into this problem :( -Chris
* Christopher L. Morrow:
its a both directions thing. Some folks dropped tcp/53 TO their AUTH servers to protect against AXFR's from folks not their normal secondaries.
Ugh. And they didn't think something like "permit tcp any any eq 53 established" was necessary?
Hopefully not. Resolvers MUST be able to make TCP connections to other name servers.
It seems that what might be more common is resolver code not handling the truncate request properly :(
Caching resolvers or stub resolvers? Caching resolvers would be quite surprising, but you never know. Certainly, there are some applications which cannot cope with large RR sets (qmail comes to my mind).
On Tue, 26 Apr 2005, Florian Weimer wrote:
* Christopher L. Morrow:
its a both directions thing. Some folks dropped tcp/53 TO their AUTH servers to protect against AXFR's from folks not their normal secondaries.
Ugh. And they didn't think something like "permit tcp any any eq 53 established" was necessary?
that only helps for outbound from the server :( not: "Hey, this response is going to be too big, come back on TCP!" :(
Hopefully not. Resolvers MUST be able to make TCP connections to other name servers.
It seems that what might be more common is resolver code not handling the truncate request properly :(
Caching resolvers or stub resolvers? Caching resolvers would be quite surprising, but you never know.
I've seen Windows DNS servers misbehave in this way as well as some firewalls performing DNS cache/proxy for clients internal to enterprises... (the ms boxen doing it was cache servers of course)
Certainly, there are some applications which cannot cope with large RR sets (qmail comes to my mind).
oh, that has to suck for email delivery, eh? :(
On Tue, Apr 26, 2005 at 07:01:47PM +0000, Christopher L. Morrow <christopher.morrow@mci.com> wrote a message of 29 lines which said:
Even after I imagine that folks left the filters in place either 'because' or 'I don't run router acls' or 'laziness'....
[Warning, operational content.] Remember that most "firewalls" or other "middleboxes" on the Internet are completely unmanaged. They were configured once and for all. (See the problems with former bogons or with 192.0.0.0/8.) The architecture of the Internet was designed for a network where all the routers were heavily managed and by knowledgeable people. Now, the switch to a network of mostly unmanaged boxes is a big challenge.
On Apr 26, 2005, at 2:45 PM, Florian Weimer wrote:
* Patrick W. Gilmore:
At least one DoS mitigation box uses TCP53 to "protect" name servers. Personally I thought this was a pretty slick trick, but it appears to have caused a lot of problems. From the thread (certainly not a scientific sampling), many people seem to be filtering port 53 TCP to their name servers.
"To their name servers"? I think you mean "from their caching resolvers to 53/TCP on other hosts".
Either. Both.
Is this common?
Hopefully not. Resolvers MUST be able to make TCP connections to other name servers.
I hope not as well, but people have posted here that they are doing so. Which is why I am asking. :-)
Does anyone have stats on this (roots, GTLDs, other big name server farms)?
What kind of stats? I might be able to provide some statistics about TC flag usage, but I doubt that this data is interesting.
I am interested in how many name servers - caching or authoritative - are filtering incoming and/or outgoing TCP port 53. _Personally_ I am most interested in what percentage of caching name servers are incapable (either because of filters, software limitations, or any other reason) of making TCP queries. More generally, I am interested in how many name servers are filtering TCP53 in any direction. -- TTFN, patrick
On Tue, Apr 26, 2005 at 03:04:25PM -0400, Patrick W. Gilmore <patrick@ianai.net> wrote a message of 46 lines which said:
I am interested in how many name servers - caching or authoritative - are filtering incoming and/or outgoing TCP port 53.
For authoritative name servers of TLD, you can browse: http://www.generic-nic.net/dyn/mon/ And see that incoming TCP is often filtered, even on serious TLD: w: Server doesn't listen/answer on port 53 for TCP protocol * Ref: IETF RFC1035 (p.32 4.2. Transport) The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can be used for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance. * ns.cnc.ac.cn./159.226.1.1 * ns.cernet.net./202.112.0.44
On Tue, Apr 26, 2005 at 12:39:09PM -0400, Patrick W. Gilmore <patrick@ianai.net> wrote a message of 22 lines which said:
From the thread (certainly not a scientific sampling), many people seem to be filtering port 53 TCP to their name servers.
Again, a non-scientific sampling but AFNIC (".fr" registry) *requires* a successful technical check of the name servers *before* delegation or technical change of a ".fr" domain. <soapbox>Every TLD should do so.</soapbox> Among the things we check is the TCP access to all the name servers. A lot ("lot" is not a scientific word, I know) of people complain. Very often, they are clueless ("TCP is only for zone transfers"), very often also they don't master their infrastucture (DNS hosted somewhere else, "firewall" middlebox which is an unmanaged black box, "firewall" which is managed by an external contractor on a per-change charge basis, etc).
Patrick W. Gilmore wrote:
In the thread about ns*.worldnic.com, many people were complaining about DNS responses/queries on TCP port 53.
At least one DoS mitigation box uses TCP53 to "protect" name servers. Personally I thought this was a pretty slick trick, but it appears to have caused a lot of problems. From the thread (certainly not a scientific sampling), many people seem to be filtering port 53 TCP to their name servers.
I know that many people to block 53/TCP to their nameservers or from their resolvers. Firewall configs are widely based on rumours ("I've heard DNS runs on UDP/53"), not based on protocol definitions. The problem is, that blocking TCP/53 outgoing from your resolver will work in 99% (wild guess) of all cases and therefore if it does not work for resolving manyrecords.example.com it obiviously is the fault of example.com. Many "security experts" believe that 53/TCP is only used for zone transfers. Nils
participants (5)
-
Christopher L. Morrow -
Florian Weimer -
Nils Ketelsen -
Patrick W. Gilmore -
Stephane Bortzmeyer