<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div style="RIGHT: auto"><SPAN style="RIGHT: auto">Dear Vernon,</SPAN></div>
<div style="RIGHT: auto"><SPAN style="RIGHT: auto"></SPAN> </div>
<div style="RIGHT: auto"><SPAN style="RIGHT: auto">Thanks for your wonderful and detailed reply. I read the update given by you as below.</SPAN></div>
<div style="RIGHT: auto"><SPAN style="RIGHT: auto"></SPAN> </div>
<div style="RIGHT: auto"><SPAN style="RIGHT: auto">>Many stateful firewalls can also record the source and destination<BR>>IP addresses and port numbers of outgoing UDP packets and allow<BR>>subsequent incoming UDP packets with source and destination reversed.<BR>>This has nothing to do with TCP.</SPAN></div>
<div style="RIGHT: auto"><SPAN style="RIGHT: auto"></SPAN> </div>
<div style="RIGHT: auto"><SPAN style="RIGHT: auto"> I am using stateful firewall and still why my BIND DNS server connection iniated using source port 53 to remote DNS server on non standard destination port is getting blocked?</SPAN></div>
<div style="BACKGROUND-COLOR: transparent; FONT-STYLE: normal; FONT-FAMILY: times new roman, new york, times, serif; COLOR: rgb(0,0,0); FONT-SIZE: 16px; RIGHT: auto"><SPAN style="RIGHT: auto"></SPAN> </div>
<div style="BACKGROUND-COLOR: transparent; FONT-STYLE: normal; FONT-FAMILY: times new roman, new york, times, serif; COLOR: rgb(0,0,0); FONT-SIZE: 16px; RIGHT: auto"><SPAN style="RIGHT: auto"> Not sure why my DNS server is initiating the connection to remote DNS server on non standard destination Port?</SPAN></div>
<div style="BACKGROUND-COLOR: transparent; FONT-STYLE: normal; FONT-FAMILY: times new roman, new york, times, serif; COLOR: rgb(0,0,0); FONT-SIZE: 16px; RIGHT: auto"><SPAN style="RIGHT: auto"></SPAN> </div>
<div style="BACKGROUND-COLOR: transparent; FONT-STYLE: normal; FONT-FAMILY: times new roman, new york, times, serif; COLOR: rgb(0,0,0); FONT-SIZE: 16px; RIGHT: auto"><SPAN style="RIGHT: auto">Regards</SPAN></div>
<div style="BACKGROUND-COLOR: transparent; FONT-STYLE: normal; FONT-FAMILY: times new roman, new york, times, serif; COLOR: rgb(0,0,0); FONT-SIZE: 16px; RIGHT: auto"><SPAN style="RIGHT: auto">Babu<VAR id=yui-ie-cursor></VAR></div></SPAN>
<div style="BACKGROUND-COLOR: transparent; FONT-STYLE: normal; FONT-FAMILY: times new roman, new york, times, serif; COLOR: rgb(0,0,0); FONT-SIZE: 16px; RIGHT: auto"> </div>
<div style="RIGHT: auto"> </div>
<div style="RIGHT: auto"> </div>
<DIV style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">
<DIV style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">
<DIV dir=ltr><FONT size=2 face=Arial>
<DIV style="BORDER-BOTTOM: #ccc 1px solid; BORDER-LEFT: #ccc 1px solid; PADDING-BOTTOM: 0px; LINE-HEIGHT: 0; MARGIN: 5px 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; HEIGHT: 0px; FONT-SIZE: 0px; BORDER-TOP: #ccc 1px solid; BORDER-RIGHT: #ccc 1px solid; PADDING-TOP: 0px" class=hr contentEditable=false readonly="true"></DIV><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Vernon Schryver <vjs@rhyolite.com><BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> bind-users@lists.isc.org <BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, 25 March 2013 8:40 PM<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> Re: Suspecious DNS traffic<BR></FONT></DIV><BR>> > Still not convinced because if i need to allow >1024 port from our <BR>> > DNS server to external world(internet).. where is the security?<BR><BR>Every UDP and TCP packet has two port numbers, the source port and<BR>the destination port. When a
resolver sends a request to a distant<BR>DNS authority, it sends to destination port 53 with a random local<BR>source port number. When the distant resolver responds, it will<BR>send a UDP packet with source port 53 and with destination port<BR>equal to the source port number in the request. If you block all<BR>packets from port 53 to local ports other than 53, then you will<BR>block all response to your resolver's requests.<BR><BR>Some DNS resolver software in ancient days sent requests to distant<BR>authorities with source port 53, so that both the source and destination<BR>port numbers in DNS/UDP packets were 53. There are many reasons why<BR>that was a bad idea. For one modern reason, see<BR><A href="https://www.google.com/search?q=cache+poisoning+attack" target=_blank>https://www.google.com/search?q=cache+poisoning+attack</A> and<BR><A href="https://www.google.com/search?q=dns+source+port+randomization"
target=_blank>https://www.google.com/search?q=dns+source+port+randomization</A><BR><BR>Contrary to claims in this thread, that source port need not be greater<BR>than 1024 except on some operating systems. The notion of "privileged<BR>ports" smaller than 1024 is an ancient "BSDism" that many consider a<BR>mistake. However, the source ports in DNS/UDP requests (as well as<BR>DNS/TCP) are likely to be restricted to parts of the complete [1,65535]<BR>range of port nubmers, but those partial ranges depend on the operating<BR>system, operating system configuration, DNS resolver software, and the<BR>resolvers configuration. For TCP and stub DNS resolvers, see<BR><A href="https://www.google.com/search?q=ephemeral+port" target=_blank>https://www.google.com/search?q=ephemeral+port</A><BR>For DNS/UDP and BIND as a resolver, see the BIND Administrators Reference<BR>Manual (ARM) including the query-source,use-v4-udp-ports,
use-v6-udp-ports,<BR>avoid-v4-udp-ports, and avoid-v6-udp-ports options.<BR><BR><BR>> You send request via UDP from random high port to an authoritative server. <BR>> Answer is too large to fit in UDP packet, so it responds via TCP to the <BR>> source port of the request (random high port from above). If you block <BR>> that TCP connection, you cannot receive answer to your query.<BR><BR>No, a distant DNS authority certainly does not respond via TCP after<BR>a UDP response fails to fit in a DNS/UDP packet. Instead, the distant<BR>authority responds with a DNS/UDP packet with the TC or "truncated"<BR>error bit.<BR><BR>A resolver will react to TC bits or truncation errors by making the<BR>same request with TCP unless it has already received the required<BR>data from some other DNS authority. This can happen after the local<BR>resolver has tired of waiting for an answer from one authority and<BR>sent the request to some
other authority.<BR><BR>Making a request via TCP consists of sending a TCP segment (or<BR>packet) with SYN bit sent to port 53 at the distant authority and<BR>with yet another random source port number. The distant authority<BR>will respond with a TCP segment with both the SYN and ACK bits set.<BR>The local resolver will respond with another TCP segment with both<BR>the SYN and ACK bits set. This is the famous "3-way handshake"<BR>that establishes a TCP connection. Only after the TCP connection<BR>is established does the local resolver send the DNS request through<BR>the TCP connection.<BR><BR>> Another reason for TCP replies is DNS Response Rate Limiting (RRL). <BR><BR>Not exactly.<BR><BR>> Some "modern" stateful firewalls understand DNS and if there is a UDP <BR>> packet sent to port 53, it will accept TCP connections back from the <BR>> destination address on port 53 to the source address/port.<BR><BR>That is
wrong. UDP packets have nothing to do with telling reasonable<BR>firewalls to allow TCP.<BR><BR>Firewalls for more than 10 years have automatically dealt with TCP<BR>in at least two ways. One is to notice and remember (i.e. save<BR>state) the initial TCP SYN segment 3-way handshake and allow the<BR>later predictaBle TCP segments. Another mechanism is to blindly<BR>block incoming TCP segments with SYN but without ACK. The first<BR>mechanism requires saving state or memory for every established TCP<BR>connection, and so can be vulnerable to some kinds of "state<BR>exhaustion attacks." The second mechanism prevents outsiders from<BR>originating TCP connections, but does not protect against using the<BR>local system for some kinds of reflection DoS attacks.<BR><BR>Many stateful firewalls can also record the source and destination<BR>IP addresses and port numbers of outgoing UDP packets and allow<BR>subsequent incoming UDP packets
with source and destination reversed.<BR>This has nothing to do with TCP.<BR><BR><BR>Vernon Schryver <A href="mailto:vjs@rhyolite.com" ymailto="mailto:vjs@rhyolite.com">vjs@rhyolite.com</A><BR>_______________________________________________<BR>Please visit <A href="https://lists.isc.org/mailman/listinfo/bind-users" target=_blank>https://lists.isc.org/mailman/listinfo/bind-users</A> to unsubscribe from this list<BR><BR>bind-users mailing list<BR><A href="mailto:bind-users@lists.isc.org" ymailto="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</A><BR><A href="https://lists.isc.org/mailman/listinfo/bind-users" target=_blank>https://lists.isc.org/mailman/listinfo/bind-users</A><BR><BR><BR></DIV></DIV></div></body></html>