TCP Receive Error

Barry Margolin barmar at alum.mit.edu
Wed Aug 2 23:55:56 UTC 2006


In article <earbuh$tfn$1 at sf1.isc.org>,
 Mark Andrews <Mark_Andrews at isc.org> wrote:
> > On my caching nameserver I have been seeing these since July 31:
> > 
> > Aug  2 09:41:14 tesla named[18013]: dispatch 0x8face08: shutting down due
> > to TCP receive error: 68.178.211.201#53: connection reset
> > 
> > The IP is always as above or 64.202.165.202
>
> 	It's just stupid nameservers not following RFC 1035 that
> 	accept TCP connections after returning "TC" to the UDP
> 	request then they reply to the TCP/DNS query with a TCP
> 	RESET.  If they don't want to answer the query then return
> 	a refused, or perform a graceful TCP shutdown.  The TCP
> 	RESET is just plain rude.

Indeed, that's what it is:

barmar $ dig . ns @64.202.165.202 +norec
;; Truncated, retrying in TCP mode.
;; communications error to 64.202.165.202#53: connection reset

Any idea why so many sites are suddenly seeing lots of these errors?  
There are messages on the NANOG mailing list (North American Network 
Operators Group, which is mostly very knowledgeable network engineers at 
major ISPs) reporting many of these errors as well.

Both of those IP's resolve to ip-<ipaddr>.ip.secureserver.net.  They're 
also near to, but not the same as, the addresses of 
cns1.secureserver.net and cns2.secureserver.net.  So my guess is that 
they're servers that are hosting some domains that secureserver.net 
hosts.  Why would everyone suddenly be querying them so often?

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***



More information about the bind-users mailing list