228 lines
12 KiB
Plaintext
228 lines
12 KiB
Plaintext
The pdnsd FAQ
|
|
|
|
Q: There are complete and well-tested name servers around, such as the BIND.
|
|
These do also perform caching. Why should I use pdnsd?
|
|
|
|
pdnsd does not aim to be a complete name server implementation, such as the
|
|
BIND. It is optimized for caching, and you can only specify a small subset
|
|
of all dns record types pdnsd knows in your local "zone" definitions. This
|
|
of course reduces the code size drastically, and such the memory footprint.
|
|
There are some features especially interesting for dialin networks,
|
|
ordinary (non-server) internet hosts and computers that are often not
|
|
connected to to their network, e.g. notebooks (I originally wrote this
|
|
program for use with my notebook). These features are:
|
|
A:
|
|
* permanent disk cache (useful for frequent power-offs/reboots)
|
|
* usually smaller memory footprint (depends on cache size) (see next
|
|
question)
|
|
* offline-detection prevents hangs (e.g. the typical hang on startup of
|
|
some Netscape Navigator versions if not dialled in)
|
|
* better control about timeouts (also to prevent hangs)
|
|
* better control over the cache
|
|
* better run-time control
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
When I look at the process size with ps, top, gtop, or a similar tool, I
|
|
Q: see some processes with a total size well above 3.5 MB. This is much more
|
|
than e.g. BIND named (about 1.4 MB). Why?
|
|
|
|
Really, it is not. pdnsd uses multithreading, not multiprocessing. That
|
|
means that the processes share most of their process space. In the
|
|
LinuxThreads library or NPTL (Native Posix Thread Libary), which are used
|
|
by pdnsd on Linux, in fact the total process address space is shared
|
|
A: (although the processes have different stacks, these are in one process
|
|
address space). You may check this by looking at the at the process sizes
|
|
of the pdnsd threads: all should be the same. The effective size that pdnsd
|
|
occupies is thus the size of any of the processes, not the sum of those.
|
|
So, pdnsd with empty cache occupies about 800 kB, and the maximum size
|
|
should be about the cache size plus this size (in fact, ca 5-10% more).
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
Q: What do I need the status control (option -s) for?
|
|
|
|
It enables you to do some things you might or might not need. With it, you
|
|
can:
|
|
|
|
* query pdnsd's settings at runtime to debug configuration files and see
|
|
which servers are regarded to be available
|
|
A: * mark servers as available or unavailable, or force a status retest -
|
|
very handy if you want to control which servers pdnsd queries, e.g for
|
|
muliple dial-up accounts
|
|
* delete, invalidate or add DNS records - useful e.g. when you want to
|
|
build records for dynamically assigned IP addresses or domain names
|
|
* reload pdnsd's configuration file without restarting pdnsd
|
|
* print information about the contents of pdnsd's cache.
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
Q: What do I need local records (rr- and source-sections in the config file)
|
|
for?
|
|
|
|
Some resolver programs, e.g. nslookup, want to look up the name of the
|
|
server they are using before doing anything else. This option is for
|
|
defining a PTR record for your IP such that those programs get an answer
|
|
even if the name server you are caching is not available or does not offer
|
|
these records. By extension, you may also define A and SOA records. This
|
|
allows you to build very small zones without having to use a "big" name
|
|
server. It is NOT intended to replace such a complete server in anything
|
|
but VERY small networks. Alternatively, you may start a named on another
|
|
host or on the same host on another port and cache it with pdnsd in
|
|
addition to other (more distant) name servers.
|
|
A: The source section allows you to let pdnsd read in your /etc/hosts file on
|
|
startup and serve its contents. This file is used by your local resolver
|
|
before it even tries the name servers and usually contains fully-qualified
|
|
domain names (FQDNs) for all of the internet addresses your host has. If
|
|
you source this file, you usually won't need any additional rr sections.
|
|
Sourcing it also allows other hosts (eg. in your local network) to access
|
|
the names defined in your hosts file. You can of course just add other
|
|
hosts in your local network to the servers hosts file, thus making them
|
|
known to your server's resolver and pdnsd (if you sourced that file).
|
|
If you don't know what this answer was all about, you should just take the
|
|
source section in the sample config file that comes with pdnsd, copy it
|
|
into your config file and forget about it.
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
When compiling, I get an error message like
|
|
Q: Please define __BYTE_ORDER to be __LITTLE_ENDIAN or __BIG_ENDIAN
|
|
What's up?
|
|
|
|
Normally, this macros should be defined in your C library's header files.
|
|
There are two different methods, most C libraries support both (and pdnsd
|
|
honors both): either __BYTE_ORDER is set to __LITTLE_ENDIAN or
|
|
__BIG_ENDIAN, or __LITTLE_ENDIAN or __BIG_ENDIAN are directly defined as
|
|
macros.
|
|
Linux glibc, for example, does set those macros correctly. Never mind. You
|
|
just have to know whether your machine is little-endian or big-endian, this
|
|
means wheter your machine saves the least significant byte of a word or
|
|
double-word first in memory (little-endian) or the most significant first
|
|
A: (big-endian). All intel x86 and Alpha machines are little-endian, for
|
|
example, while SPARC and PowerPC architectures are big-endian. If your
|
|
machine is little-endian, add the following line to your config.h:
|
|
#define __BYTE_ORDER __LITTLE_ENDIAN
|
|
Likewise, if your machines byte order is big-endian:
|
|
#define __BYTE_ORDER __BIG_ENDIAN
|
|
Pathological byte orders like pdp-endian are not yet supported really;
|
|
However, for the place the endianess is needed, __LITTLE_ENDIAN should do
|
|
(it deals only with 16 bits; for all other occurances, ntoh[sl]/hton[sl] is
|
|
used).
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
At startup, I get a warning saying:
|
|
Q: Uptest command [...] will implicitly be executed as root
|
|
What does that mean?
|
|
|
|
This warning only occurs if you use the uptest=exec option in your
|
|
configuration. It means that the uptest command is run as root because
|
|
pdnsd is running as root, and this was not explicitely specified. The idea
|
|
is that it may introduce security holes (in the programs being run) when
|
|
A: they run as root, and so they shouldn't do that if possible. You can
|
|
specify the user that shall run the command by appending its name
|
|
comma-separated as string to the uptest_cmd line:
|
|
uptest_cmd="<your command>","<user>";
|
|
If it is correctly running as root, just append the user string "root" to
|
|
the command and the warning will not occur again.
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
Q: I cannot run my uptest_cmd command as root (it says permission denied),
|
|
although the pdnsd executable is setuid root. Why?
|
|
|
|
pdnsd will drop privileges gained through setuid/setgid before executing
|
|
the uptest commands (you shouldn't set the pdnsd executable setuid/setgid
|
|
A: anyway). The reason is clear: if you install the pdnsd executable as setuid
|
|
root and this wouln't be done, any user could execute shellcode with root
|
|
privileges using that option!
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
At startup, I get an error saying:
|
|
Q: Bad config file permissions: the file must be only writeable by the user
|
|
Why is that?
|
|
|
|
pdnsd has an option (uptest=exec) that allows the execution of arbitrary
|
|
shell code (for testing whether an interface is up). This must be of course
|
|
secured against unauthorized use. One of these protection is the one that
|
|
produces the error message: if you routinely run pdnsd, e.g. at system
|
|
startup, and your config file is editable for others, someone could change
|
|
A: it and insert shell code that is executed in the next pdnsd run -- with
|
|
your user privileges! To prevent this, pdnsd will exit if the config file
|
|
is writeable by others than the owner. To get rid of this message, just do
|
|
chmod go-w <filename>
|
|
on your config file (for the default file: chmod go-w /etc/pdnsd.conf). You
|
|
should also check that the ownership is set correct.
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
Q: serve_aliases does not seem to work.
|
|
|
|
Some resolvers (e.g. of the glibc 2.1) seem sometimes not to look up
|
|
unmodified names, but the names with an entry of the search path already
|
|
A: appended. Since pdnsd will serve short names with this option anyway, you
|
|
can delete the search an domain options from your /etc/resolv.conf. This is
|
|
reported to work in some cases.
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
Q: Some queries for domains that have many records (e.g. www.gmx.de) fail
|
|
mysteriously.
|
|
|
|
pdnsd versions prior to 1.1.0 had the tcp server thread disabled by
|
|
default. Most resolvers repeat their query using tcp when they receive a
|
|
A: truncated answer (the answer is truncated when it exceeds a length of 512
|
|
bytes). You need to recompile pdnsd with the option --enable-tcp-server to
|
|
fix this.
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
I am behind some kind of firewall. In the configuration file I have only
|
|
Q: listed addresses of name servers on the local (ISP's) network, but pdnsd is
|
|
slow and DNS queries frequently time out.
|
|
|
|
In some cases pdnsd will not consider the answer of the local name server
|
|
authoritative enough, and will try to get answers from the name servers
|
|
listed in the authority section of the reply message. If pdnsd is behind a
|
|
firewall that blocks the UDP reply packets from remote name servers, pdnsd
|
|
will wait in vain for a reply. One solution is to set proxy_only=on in the
|
|
A: servers sections of the configuration file. This will prevent pdnsd from
|
|
querying name servers that are not listed in the configuration file.
|
|
Another solution that can be tried is specifying query_method=tcp_only in
|
|
the global section of the configuration file, because a firewall that
|
|
blocks UDP packets from outside might still allow outgoing TCP connections
|
|
to port 53.
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
Q: Is pdnsd vulnerable to DNS cache poisoning as described in CERT
|
|
vulnerability note VU#800113?
|
|
|
|
Short answer: Yes.
|
|
Somewhat longer answer: The problem is not so much that pdnsd's
|
|
implementation is flawed but rather that the DNS protocol currently being
|
|
used is fundamentally flawed from a security viewpoint. As long as a more
|
|
secure protocol is not in place, all that the developers of pdnsd can do is
|
|
to try to tweak the current implementation to make it as difficult as
|
|
possible for an attacker to succeed.
|
|
From version 1.2.7 onwards, the default for the query_port_start option is
|
|
A: 1024, which means that the pdnsd resolver will randomly select source ports
|
|
in the range 1024-65535. (In previous versions the default was to let the
|
|
kernel select the source ports, which will often result in a more or less
|
|
predictable sequence of ports.) It also helps to use a good quality source
|
|
of random numbers. On platforms where this is supported, it is preferable
|
|
to configure with --with-random-device=/dev/urandom. There is still more
|
|
that can be done to make pdnsd less vulnerable, but this remains (as of
|
|
this writing) a work in progress.
|
|
Please note that pdnsd was designed for small (private) networks, and that
|
|
it is generally not recommended to let untrusted users access pdnsd.
|
|
|
|
-------------------------------------------------------------------------------
|
|
|
|
Thomas Moestl and Paul Rombouts
|
|
|
|
|
|
Last revised: 18 August 2008 by Paul Rombouts
|
|
|