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.)
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.
* 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
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.
> 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).
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).
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.
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:
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.
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.
That seemed to be the majority of the