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