Unexpected outgoing DNS traffic & "connection reset"

Pete Ehlke pde at rfc822.net
Sun Oct 30 15:55:00 UTC 2005


On Sun Oct 30, 2005 at 07:23:15 -0500, Steve Snyder wrote:
>I'm running BIND 9.2.1 (with security patches) on a Linux system.  My 
>nameserver should only be satisfying requests from the local network, and 
>caching resolutions from outside the network.  So why do I have outgoing 
>TCP traffic to destination port 53?
>
>Here's a snippet of my named.conf:
>
>   listen-on { 127.0.0.1; 192.168.0.1; };
>   allow-query { 127.0.0.1; 192.168.0/24; };
>   allow-transfer { 192.168.0/24; };
>
>On my nameserver machine interface eth0 is 192.168.0.1 on a 192.168.0/24 
>network, and interface eth1 faces the internet (IP is obscured below as 
>"aaa.bbb.ccc.ddd").
>
>My understanding is that TCP is only used when transferring a zone which 
>is too large to fit into a UDP packet.  Given that I am (in theory) not 
>transferring zones outside my LAN, there should be no need for outgoing 
>TCP traffic to port 53, right?
>
Your understanding is incorrect. TCP is used any time the remote server
sends a respose with the truncate bit set. Historically this has meant
that the response to the query you sent will not fit in a 512 byte UDP
datagram and your server and the remote server to not both support
EDNS0. Some DNS hosting services today truncate the response to the
first query from a given IP address, forcing a TCP retry, as a method to
mitigate against certain types of DoS attacks. Regardless of your
opinion on the wisdom of this technique, it's out there, and it seems to
be reasonably within the spirit of the RFCs. secureserver.net engages in
this tactic:

[ pete at bryce:~]$ dig @64.202.165.4
;; Truncated, retrying in TCP mode.
;; communications error to 64.202.165.4#53: connection reset

[ pete at bryce:~]$ dig @64.202.165.4

; <<>> DiG 9.3.1 <<>> @64.202.165.4
; ( 1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19170
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;.                              IN      NS

;; Query time: 52 msec
;; SERVER: 64.202.165.4#53( 64.202.165.4)
;; WHEN: Sun Oct 30 10:41:36 2005
;; MSG SIZE  rcvd: 17

( The fact that secureserver engage in certain other dodgy and
antisocial practices like dropping and failing to respond to some
queries is beside the point in this case. )

The point for you is that TCP is not optional for the correct operation
of a name server. Your firewall rules are incorrect. You must allow TCP
to and from your name server.

-Pete



More information about the bind-users mailing list