> > 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 [email protected] _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/bind-users
