FTP, DNS Names, and IP Addresses
FTP is an IP address-based protocol. FTP clients connect to specific
IP address/port combinations; FTP servers handle client connections by
listening on IP addresses. No DNS or host names are exchanged by clients
and servers. FTP does not support name-based virtual hosts, as HTTP 1.1
does.
The above may seem obvious, but it must be reiterated often. Users can become confused, since FTP clients and servers often use DNS names, rather than explicit IP addresses. This is not surprising, as DNS names are easier to use than IP addresses. The clients and servers resolve those DNS names to their IP addresses, behind the users' backs.
All of this means that whenever proftpd
is given a DNS name,
it will resolve that DNS name to its IP address, and then use the IP
address.
When are DNS Names Resolved?
When proftpd
starts up and parses its configuration file,
it expects to handle DNS names in the following configuration directives,
if they are present:
Allow DefaultAddress Deny From MasqueradeAddress <VirtualHost>Note that if a DNS name resolves to an IPv6 address (and
proftpd
has been compiled with IPv6 support via the --enable-ipv6
configure option), then proftpd
will handle it properly.
Otherwise proftpd
will attempt resolutions to IPv4 addresses
only.
Even if none of the above configuration directives are used,
proftpd
will still perform at least one DNS lookup: it will
resolve the hostname of the server on which the daemon is running, i.e.
the name displayed by typing `hostname`
. Why does
proftpd
need to know this? There is always at least one
server that proftpd
will handle: the "server config"
server (see the virtual host howto). This "server config"
server defaults to the IP address of the hostname of the machine.
Once proftpd
has the complete list of IP addresses with which
it work will while running, it completes its startup, and is ready to
handle connections from FTP clients. The running daemon will continue
doing DNS lookups when necessary. For example, every time connection is made
to a proftpd
daemon, or proftpd
connects back
to a client (as when handling active data transfers), the remote IP address
is resolved to its DNS name. In addition, once the DNS name is
found, that name is resolved back to an IP address. Why the additional
step, when we already have the original IP address? It is possible,
either through ignorance or maliciousness, to configure DNS such that an
IP address will map to a name, and that name will map back to a different
IP address. Configurations such this can be used to foil some DNS-based
ACLs. ProFTPD now deliberately checks for such configurations.
DNS resolution from an IP address and back can add noticeable
delays to the FTP session, particularly when there are many data transfers
occurring and proftpd
is performing the reverse DNS lookup for
each one. This penalty can easily be removed by using the
UseReverseDNS
configuration directive:
UseReverseDNS offHowever, you should do this only if you do not have ACLs that rely on DNS names. Otherwise, your ACLs will not work as you expect. Also, if
UseReverseDNS
is off, proftpd
will log only IP addresses in its logs, rather than more legible
DNS names.
Clever users of ProFTPD know that you can use the Port
directive to "disable" a given virtual host (including the
"server config" host) by setting a port number of zero:
Port 0By disabling the virtual host that way, can you prevent
proftpd
from resolving the IP address for that host? No. Using the
Port 0
trick like this is a hack that affects the process
used to lookup the configuration to use for a client connection; it does
not affect the parser, which handles the address lookup when
the daemon is starting up.
Frequently Asked Questions
Question: Why do I see the following when my
proftpd
starts up?
getaddrinfo 'hostname' error: No address associated with hostname
warning: unable to determine IP address of 'hostname'
Answer: This error is ProFTPD's way of reporting that
it was unsuccessful in resolving hostname to an IP address. Fixing
this is a matter of configuring DNS for that hostname: properly set
up an IP address for that DNS name in your DNS server, use a DNS name that has
an IP address, or (as a quick fix/last resort) add that DNS name to your
/etc/hosts
file. The proper solution depends largely on
the circumstances.