-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It sounds like exactly the reverse of what Niall described in his other e-mail (brackets mine):
"The reply to such a query originates from port 53 on the remote server [in this case, your server], and is destined for the port on your server [in this case, the remote server] which was used as the source of the query [which will, again, almost certainly be a random port above 1024, but the same port the request just came in from to your port 53]." Why your firewall is confused about this is anyone's guess. I'd check with them. On 03/26/2013 02:50 PM, babu dheen wrote: > Dear Vernon, > > Thanks for your wonderful and detailed reply. I read the update > given by you as below. > >> Many stateful firewalls can also record the source and >> destination IP addresses and port numbers of outgoing UDP packets >> and allow subsequent incoming UDP packets with source and >> destination reversed. This has nothing to do with TCP. > > 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? > > Not sure why my DNS server is initiating the connection to remote > DNS server on non standard destination Port? > > Regards Babu > > > > *From:* Vernon Schryver <v...@rhyolite.com> *To:* > bind-users@lists.isc.org *Sent:* Monday, 25 March 2013 8:40 PM > *Subject:* Re: Suspecious DNS traffic > >>> Still not convinced because if i need to allow >1024 port from >>> our DNS server to external world(internet).. where is the >>> security? > > Every UDP and TCP packet has two port numbers, the source port and > the destination port. When a resolver sends a request to a > distant DNS authority, it sends to destination port 53 with a > random local source port number. When the distant resolver > responds, it will send a UDP packet with source port 53 and with > destination port equal to the source port number in the request. > If you block all packets from port 53 to local ports other than 53, > then you will block all response to your resolver's requests. > > Some DNS resolver software in ancient days sent requests to > distant authorities with source port 53, so that both the source > and destination port numbers in DNS/UDP packets were 53. There are > many reasons why that was a bad idea. For one modern reason, see > https://www.google.com/search?q=cache+poisoning+attack and > https://www.google.com/search?q=dns+source+port+randomization > > Contrary to claims in this thread, that source port need not be > greater than 1024 except on some operating systems. The notion of > "privileged ports" smaller than 1024 is an ancient "BSDism" that > many consider a mistake. However, the source ports in DNS/UDP > requests (as well as DNS/TCP) are likely to be restricted to parts > of the complete [1,65535] range of port nubmers, but those partial > ranges depend on the operating system, operating system > configuration, DNS resolver software, and the resolvers > configuration. For TCP and stub DNS resolvers, see > https://www.google.com/search?q=ephemeral+port For DNS/UDP and BIND > as a resolver, see the BIND Administrators Reference Manual (ARM) > including the query-source,use-v4-udp-ports, use-v6-udp-ports, > avoid-v4-udp-ports, and avoid-v6-udp-ports options. > > >> You send request via UDP from random high port to an >> authoritative > server. >> Answer is too large to fit in UDP packet, so it responds via TCP >> to the source port of the request (random high port from above). >> If you block that TCP connection, you cannot receive answer to >> your query. > > No, a distant DNS authority certainly does not respond via TCP > after a UDP response fails to fit in a DNS/UDP packet. Instead, > the distant authority responds with a DNS/UDP packet with the TC or > "truncated" error bit. > > A resolver will react to TC bits or truncation errors by making > the same request with TCP unless it has already received the > required data from some other DNS authority. This can happen after > the local resolver has tired of waiting for an answer from one > authority and sent the request to some other authority. > > Making a request via TCP consists of sending a TCP segment (or > packet) with SYN bit sent to port 53 at the distant authority and > with yet another random source port number. The distant authority > will respond with a TCP segment with both the SYN and ACK bits > set. The local resolver will respond with another TCP segment with > both the SYN and ACK bits set. This is the famous "3-way > handshake" that establishes a TCP connection. Only after the TCP > connection is established does the local resolver send the DNS > request through the TCP connection. > >> Another reason for TCP replies is DNS Response Rate Limiting >> (RRL). > > Not exactly. > >> Some "modern" stateful firewalls understand DNS and if there is a >> UDP packet sent to port 53, it will accept TCP connections back >> from the destination address on port 53 to the source >> address/port. > > That is wrong. UDP packets have nothing to do with telling > reasonable firewalls to allow TCP. > > Firewalls for more than 10 years have automatically dealt with TCP > in at least two ways. One is to notice and remember (i.e. save > state) the initial TCP SYN segment 3-way handshake and allow the > later predictaBle TCP segments. Another mechanism is to blindly > block incoming TCP segments with SYN but without ACK. The first > mechanism requires saving state or memory for every established > TCP connection, and so can be vulnerable to some kinds of "state > exhaustion attacks." The second mechanism prevents outsiders from > originating TCP connections, but does not protect against using > the local system for some kinds of reflection DoS attacks. > > Many stateful firewalls can also record the source and destination > IP addresses and port numbers of outgoing UDP packets and allow > subsequent incoming UDP packets with source and destination > reversed. This has nothing to do with TCP. > > > Vernon Schryver v...@rhyolite.com <mailto:v...@rhyolite.com> > _______________________________________________ Please visit > https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list bind-users@lists.isc.org > <mailto:bind-users@lists.isc.org> > https://lists.isc.org/mailman/listinfo/bind-users > > - -- - ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$&| |__| | | |__/ | \| _| |novos...@umdnj.edu - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFR8lIACgkQmb+gadEcsb4B7QCg2f64+sltIkM6KzHV13+pFCR0 +7sAn3J/sEWHigF8MbC4+RCfowfkfyWQ =YMnI -----END PGP SIGNATURE----- _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
