DNS Ports Usage

Port usage and binary format of DNS messages is described in RFCs. Nice collection of RFCs can be found at Nominum-Resources-Standards Information-DNS RFCs

Windows DNS Service uses dynamic UDP ports (above 1023) for all standard query messages. For a W2K DNS server which is facing the Internet (acting as primary for zones, or performing root server lookups for client requests) being protected (at least in part) by router Access Control Lists (ACLs), it must now permit unrestricted UDP inbound access to any high UDP port on the W2K DNS box in order for it to work.  You need to change registry to change this behavior.

Unix DNS server behavior. It's also important to realize that  UNIX  OS doesn't have any sort of "resolver daemon" nor is this a function of the kernel (a system call or device driver or anything like that). This is just a set of libraries to which almost all other applications are linked.

• DNS uses mainly UDP not TCP
  
• Zone transfers and in modern servers usually are TCP.
  
• Client server communications:
  • Request: client (libresolv) random above 1023 -> server (named) port 53
    
  • Response: server port 53 -> client same port that request was sent from
    
• Name server to name server:
  53 -> 53
  53 <- 53

Here is the post from Matt Harrington (Jan 02, 2000) on the SAGE (USENIX Sysadmin's Guild) list that nicely summarize Unix DNS server behavior.

Q: Is the following true or false? A client talks to a nameserver on port 53/tcp. the nameserver answers back on a random udp port greater than 1023.

It is false. An FAQ that will answer your question is at:

http://www.intac.com/~cdp/cptd-faq/section2.html#ports

... However, I'll also add some detail here.

First point: normal DNS resolution occurs over UDP.

The usual sequence for a UNIX client is something like this:

The application executes a call to "gethostbyname()" (a standard library function, which is linked into the libc on almost any UNIX platform). gethostbyname() in glibc (Linux libc version 6.x) is implemented to look at the contents of your /etc/nsswitch.conf file, and apply a set of rules from that to load NSS (name services systems) libraries. Most Linux systems are configured to use libnsscompat.so --- which uses NIS/NIS+, DNS and traditional UNIX files (/etc/hosts, /etc/networks). You can see all of the NSS libraries on most Linux systems using the command:

ls /lib/libnss*

... although you might have to look at the contents of /etc/ld.so.conf for a list of other directories in which other libnss libraries might exist.

Entries in /etc/nsswitch.conf will refer to these libraries (take the basename of the library file and trim off the "libnss" prefix to relate library name to the nsswitch.conf keyword).

Before I get back to describing the DNS IP protocols (your question) I'll mention that all this complexity and redirection is actually useful since it allows an admin to configure his Linux (or other GNU system) to use files, DNS, NIS, NIS+, as well as more obscure Hesiod, and new LDAP and NDS naming/directory services without having to recompiling any of the standard utilities on any system.

It's also important to realize that the Linux and UNIX doesn't have any sort of "resolver daemon" nor is this a function of the kernel (a system call or device driver or anything like that). This is just a set of libraries to which almost all other applications are linked.

When the system is configured to use DNS (as they almost all are) then the library functions open and read the /etc/resolv.conf file. This gives a list of DNS servers to which the resolver will direct its initial queries.

The query will be over UDP, with an arbitrary unprivileged source port and a destination port of 53 (which is the DNS query port listed in your /etc/services file).

The initial response should come from one of the DNS servers as listed in /etc/resolv.conf, and be directed back to (have a destination port equal to) the source of the query. The source of the response should also be port 53.

Notice that I mentioned "initial" queries and responses. That's because the DNS protocol allows a server to refer the client to some other DNS server. Thus there may be an initial response that amounts to: "I don't know, go ask ..."

Thus the standard packet filtering rules that you're thinking about require one to allow UDP traffic from port 53 to any unprivileged port in your domain.

Naturally this seems a bit too loose. One approach is to have the firewall track outstanding DNS requests maintaining a context state and only permitting responses back to host/port pairs that have outstanding DNS queries. This is call "stateful" packet inspection and it is one of the features that distinguishes a "firewall" from a simple "packet filter."

(Actually I hate to use the term "firewall" because it is so nebulous. However, I have to simplify a bit or I can't say anything).

A better approach is to configure your caching name server(s) so they never forward clients to other name servers. Thus you can have one or more "sacrificial" caching nameservers on your perimeter network, allow all DNS traffic to those, and have a set of rules on the interior router/packet filters that allows all DNS traffic from those to your hosts.

This is the architecture I recommend.

NEWS CONTENTS

• 210210 : [isp-dns] Re BIND 9 port usage ( [isp-dns] Re BIND 9 port usage , )
• 210210 : The TCP-IP Guide - DNS Message Generation and Transport ( The TCP-IP Guide - DNS Message Generation and Transport, )
• 210210 : Neohapsis Archives - NTBugtraq - W2K DNS port usage changes ( Neohapsis Archives - NTBugtraq - W2K DNS port usage changes, )
• 210210 : DNS Port(s) ( DNS Port(s), )
• 210210 : Re DNS ports... ( Re DNS ports..., )
• 210210 : The Answer Guy 50 DNS Ports A bit about Name Resolution Protocols ( The Answer Guy 50 DNS Ports A bit about Name Resolution Protocols , )

Old News ;-)

[isp-dns] Re BIND 9 port usage

• To: [email protected]
• Subject: [isp-dns] Re: BIND 9 port usage
• From: Pete Ehlke
• Date: Tue, 27 May 2003 12:44:00 -0500

On Tue, May 27, 2003 at 11:10:38AM -0600, Jim McAtee wrote:
> I just upgraded my two Win2k DNS servers (both are authoritative and permit
> recursion) to BIND 9.2.2 from BIND 8.
> 
> I'm running into problems resolving recursive queries as well as having some
> problems processing transfers.  I've got logging for notifies and xfers in
> and out set to debug 3.  There's a third off-site authoritative server that
> hasn't changed and the xfer-out don't end up in the logs.
> 
> I'm pretty sure the main problem lies with ports being blocked at the
> firewall.  I'm permitting port 53 UDP and TCP in and out.  Nothing else.
> This seemed to have worked fine for BIND 8, but not BIND 9.  Were there
> changes in port usage, or did I always have the firewall fubared?
> 
see query-source and transfer-source

Permitting only port 53 in and out is a broken firewall configuration
unless you specifically configure named to only talk on port 53. Doing
that is probably a mistake, because you significantly limit the space of
host-port-sequence number combinations. Limiting yourself to only port
53 outbound actually reduces the security of your DNS infrastructure.

The TCP-IP Guide - DNS Message Generation and Transport

UDP and TCP "share" level 4 in TCP/IP because they are so different in terms of capabilities and operation. Some application protocols need the services of TCP and can use it to take advantage of them, while others are better off with the simpler UDP. DNS is itself a perfect example of the valid reasons for having both UDP and TCP in the protocol suite, because it uses both.

UDP Message Transport

UDP is a simple connectionless protocol that provides no real features but is very fast. It is ideally suited for small, quick exchanges of information, and can be faster than TCP because there is no need to establish a connection. This makes it a good choice for most of the conventional queries used in DNS, because they are normally very short, and fast data exchange is important. For this reason, the DNS standards recommend use of UDP for queries and replies as part of regular and reverse name resolution. UDP DNS messages are limited to 512 bytes; longer messages are truncated and a special bit in the header is set to indicate that this has occurred. If a message being truncated causes a problem for its recipient, the query must be repeated using TCP, as described below.

Note: The 512 byte limit on DNS UDP messages can be surpassed if the optional Extension Mechanisms for DNS (EDNS0) are implemented. These are described in RFC 2671.

TCP Message Transport

Since UDP does not provide reliable delivery of messages, DNS clients must keep track of requests they have sent. If no response is received after a particular amount of time, the request must be retransmitted. The need to take care of these details is considered an acceptable trade-off for the lower setup costs involved with UDP, such as not requiring a connection. The rate at which retransmissions is sent is usually set at a minimum of 2 to 5 seconds to prevent excessive DNS traffic on the internetwork.

For certain special DNS transactions, UDP is simply inappropriate. The most common example of such a transaction is a zone transfer. While the query for a zone transfer is small in size, the amount of data sent in response can be quite large. The limit of 512 bytes for UDP is not even close to enough. Furthermore, we really do need to make sure that a zone transfer is accomplished reliably and with flow control and other data transfer management features, or we risk having corrupted zone information in our secondary DNS server databases.

The solution is to use TCP for these types of exchanges. TCP allows messages to be of arbitrary length, and as a connection-oriented, acknowledged, reliable protocol, automatically provides the mechanisms we need to ensure that zone transfers and other lengthy operations complete successfully. The cost is the small amount of overhead needed to establish the connection, but since zone transfers are infrequent (compared to the sheer volume of regular name resolutions) this is not a problem.

You can see how DNS nicely illustrates the roles of both TCP and UDP in TCP/IP. Since both transport protocols can be used, name servers listen for both UDP and TCP requests on the same well-known port number, 53. The device acting as the client uses an ephemeral port number for the transaction. All DNS messages are sent unicast from one device directly to another.

Key Concept: DNS uses both UDP and TCP to send messages. Conventional message exchanges are "short and sweet" and thus well-suited to the use of the very fast UDP; DNS itself handles the detection and retransmission of lost requests. For larger or more important exchanges of information, especially zone transfers, TCP is used-both for its reliability and its ability to handle messages of any size.

Neohapsis Archives - NTBugtraq - W2K DNS port usage changes

Subject: W2K DNS port usage changes
From: Russ
Date: Tue Mar 21 2000 - 14:03:28 CST

• Next message: Chris Brenton: "Re: W2K DNS port usage changes"
• Previous message: Tom Yergeau: "Re: Terminal Service for Win2k fails when High Encryption is selected and 128-bit encryption pack has been applied"
• Next in thread: Chris Brenton: "Re: W2K DNS port usage changes"
• Reply: Chris Brenton: "Re: W2K DNS port usage changes"
• Reply: Russ: "Re: W2K DNS port usage changes"
• Reply: Marc Slemko: "Re: W2K DNS port usage changes"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

---

Problem:

Windows 2000 Server or Advanced Server DNS Service uses dynamic UDP ports (above 1023) for all standard query messages.

For a W2K DNS server which is facing the Internet (acting as primary for zones, or performing root server lookups for client requests) being protected (at least in part) by router Access Control Lists (ACLs), it must now permit unrestricted UDP inbound access to any high UDP port on the W2K DNS box in order for it to work.

Note, this is a change from NT 4.0 DNS server which always performed all such lookups using UDP 53 as a source port (thereby allowing router ACLs to restrict access to port UDP 53 on the DNS server.)

I have not checked to see if this is, or isn't, in line with current DNS RFCs. What it means, however, is that a UDP port scan can be performed on any W2K box with a DNS configured as above (which is being protected, at least in part, by router ACLs) as long as the source port of the scan is UDP 53. Since RPC is still in use on W2K, numerous services may be listening on high UDP ports which you wouldn't want interrogated.

I would be interested to hear about other DNS servers and whether they use dynamic source ports for such queries.

Status:

Microsoft had implemented a registry key that would permit you to restrict the source port on the DNS server to a single port. The "SendPort" key was intended to serve this functionality, however, it doesn't work...;-[ Microsoft are researching a fix (presumably fixing whatever is broken in the "SendPort" functionality).

Meanwhile, might be wise to ensure that your Internet-facing DNS server isn't running Windows 2000.

Cheers,
Russ - NTBugtraq Editor

DNS Port(s)

At 10:00 AM +0000 3/4/2000, Simon Forster wrote:
>Quick ?
>
>DNS services happen on port 53 but how/what ports does QuickDNS use to
>transfer data for secondary services.
>
>Perhaps I should explain. I have my QuickDNS server behind a firewall.
>Everything works fine at the moment 'cause I allow all requests through to
>this machine but I'd like to limit it to just having the ports required for
>full DNS services open so...
>
>I need to open port 53 for UDP but do I need to open another port?

DNS queries are usually, but not always, sent on UDP port 53. Some programs (dig, for ex.) send them on TCP port 53.

Zone transfers usually happen through TCP port 53. Some programs (dig, for example) request zone transfers through UDP port 53.

All standards-based DNS traffic happens on port 53, either UDP or TCP. Non-standards-based DNS traffic would include such things as the LPM packets used in QuickDNS' fault tolerance.

Re DNS ports...

DNS is udp not tcp

Zone transfers can be tcp.

Request: client (libresolv) random above 1023 -> server (named) port 53

Response: server port 53 -> client same port that request was sent from

name server to name server:
53 -> 53
53 <- 53

The Answer Guy 50 DNS Ports A bit about Name Resolution Protocols From Matt Harrington on Sun, 02 Jan 2000 on the SAGE (USENIX Sysadmin's Guild) list

Q: Is the following true or false? A client talks to a nameserver on port 53/tcp. the nameserver answers back on a random udp port greater than 1023.

It is false. An FAQ that will answer your question is at:

http://www.intac.com/~cdp/cptd-faq/section2.html#ports

... However, I'll also add some detail here.

First point: normal DNS resolution occurs over UDP.

The usual sequence for a UNIX client is something like this:

The application executes a call to "gethostbyname()" (a standard library function, which is linked into the libc on almost any UNIX platform). gethostbyname() in glibc (Linux libc version 6.x) is implemented to look at the contents of your /etc/nsswitch.conf file, and apply a set of rules from that to load NSS (name services systems) libraries. Most Linux systems are configured to use libnsscompat.so --- which uses NIS/NIS+, DNS and traditional UNIX files (/etc/hosts, /etc/networks). You can see all of the NSS libraries on most Linux systems using the command:

ls /lib/libnss*

... although you might have to look at the contents of /etc/ld.so.conf for a list of other directories in which other libnss libraries might exist.

Entries in /etc/nsswitch.conf will refer to these libraries (take the basename of the library file and trim off the "libnss" prefix to relate library name to the nsswitch.conf keyword).

Before I get back to describing the DNS IP protocols (your question) I'll mention that all this complexity and redirection is actually useful since it allows an admin to configure his Linux (or other GNU system) to use files, DNS, NIS, NIS+, as well as more obscure Hesiod, and new LDAP and NDS naming/directory services without having to recompiling any of the standard utilities on any system.

It's also important to realize that the Linux and UNIX doesn't have any sort of "resolver daemon" nor is this a function of the kernel (a system call or device driver or anything like that). This is just a set of libraries to which almost all other applications are linked.

When the system is configured to use DNS (as they almost all are) then the library functions open and read the /etc/resolv.conf file. This gives a list of DNS servers to which the resolver will direct its initial queries.

The query will be over UDP, with an arbitrary unprivileged source port and a destination port of 53 (which is the DNS query port listed in your /etc/services file).

The initial response should come from one of the DNS servers as listed in /etc/resolv.conf, and be directed back to (have a destination port equal to) the source of the query. The source of the response should also be port 53.

Notice that I mentioned "initial" queries and responses. That's because the DNS protocol allows a server to refer the client to some other DNS server. Thus there may be an initial response that amounts to: "I don't know, go ask ..."

Thus the standard packet filtering rules that you're thinking about require one to allow UDP traffic from port 53 to any unprivileged port in your domain.

Naturally this seems a bit too loose. One approach is to have the firewall track outstanding DNS requests maintaining a context state and only permitting responses back to host/port pairs that have outstanding DNS queries. This is call "stateful" packet inspection and it is one of the features that distinguishes a "firewall" from a simple "packet filter."

(Actually I hate to use the term "firewall" because it is so nebulous. However, I have to simplify a bit or I can't say anything).

A better approach is to configure your caching name server(s) so they never forward clients to other name servers. Thus you can have one or more "sacrificial" caching nameservers on your perimeter network, allow all DNS traffic to those, and have a set of rules on the interior router/packet filters that allows all DNS traffic from those to your hosts.

This is the architecture I recommend.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Created May 16, 1996; Last modified: July 28, 2019