|
Softpanorama
(slightly skeptical)
Open Source Software Educational Society |
May the
source be with you,
but remember the KISS principle ;-)
|
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 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. You need
to change registry to change this behavior.
Unix DNS server behavior
- 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.
- To:
isp-dns@isp-dns.com
- 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.
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. |
Subject: W2K DNS port usage changes
From: Russ
Date: Tue Mar 21 2000 - 14:03:28 CST
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
From: Men & Mice Support
Date: Saturday, March 4, 2000
Time: 11:11:00 am
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.
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
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.
Copyright © 1996-2008 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Created May 16, 1996; Last modified:
February 28, 2008