|pdnsd Homepage||pdnsd FAQ||Documentation||GNU GPL (pdnsd's License)||Download Section|
|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:
|Q:||When I look at the process size with ps, top, gtop, or a similar tool, I 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?|
|A:||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 (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:
|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.
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
Please define __BYTE_ORDER to be __LITTLE_ENDIAN or __BIG_ENDIAN
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
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 (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:
Likewise, if your machines byte order is big-endian:
Pathological byte orders like pdp-endian are not yet supported really; However, for the place the endianess is needed,
At startup, I get a warning saying:
Uptest command [...] will implicitly be executed as root
What does that mean?
This warning only occurs if you use the
If it is correctly running as root, just append the user string
I cannot run my
|A:||pdnsd will drop privileges gained through setuid/setgid before executing the uptest commands (you shouldn't set the pdnsd executable setuid/setgid 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:
Bad config file permissions: the file must be only writeable by the user
Why is that?
pdnsd has an option (
on your config file (for the default file:
|A:||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 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 truncated answer (the answer is truncated
when it exceeds a length of 512 bytes). You need to recompile pdnsd with the option
|Q:||I am behind some kind of firewall. In the configuration file I have only 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
|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
Please note that pdnsd was designed for small (private) networks, and that it is generally not recommended to let untrusted users access pdnsd.
Last revised: 18 August 2008 by Paul Rombouts