On Mar 26, 2013, at 3:09 PM, "Novosielski, Ryan" <novos...@umdnj.edu> wrote:
> -----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. Another option is to just follow the standard dictum of "Don't put your DNS server behind a firewall". It almost always makes debugging much harder and either monkeys with stuff that it shouldn't, or simply provides no benefit, all while adding another thing to fall over under DoS conditions. W > > 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 > -- Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup. _______________________________________________ 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
