New DJBDNS-1.05.6


I feel happy to announce yet another release of the New DJBDNS. (New wordpress interface looks neat too.)The release 1.05.6 of N-DJBDNS fixes a major security flaw in the DNS resolver, which would allow an attacker to keep a domain name alive in the resolver cache, even after it has been revoked by the DNS server. It is known as a ghost domain attack. This release also includes the Real time Block List DNS tools: rbldns & rbldns-data. Full list of the added features, latest source and RPM packages could be accessed from

  here ->

This latest package is also available via Fedora & EPEL stable repositories. I strongly urge you to install the update via

   $ yum install ndjbdns

It has been truly wonderful to work on N-DJBDNS package; Recently a kind user conveyed his remarks:

I just wanted to thank you for N-DJBDNS.  I’ve been using djbdns (as a caching resolver) with a Fedora system since about Fedora 8.  I did have an older Fedora package, but with some of the init rewrites (systemd), having an updated RPM package makes installation quite simple.  Reported success on Fedora 18 of N-DJBDNS – post install, all I had to do was point Network Manager’s resolver to the lo,

I’d like to thank all users for using N-DJBDNS and invite those who haven’t tried it yet. I’d also like to thank Mark for filing bugs and helping me with the updated patches and reviews.

Thank you so much! 🙂

15 thoughts on “New DJBDNS-1.05.6

  1. Don’t know what I’m doing wrong, it just seems as if the version 1.05.6 ignores everything in servers/* (accecpt roots) .

    With ngrep I found out it just asks the root servers although it should be asking the configured authoritative nameservers.

    In more detail: I specify an IP address to look up anything for by doing:

    echo “” > servers/

    If I now run ‘dig @‘ I can see via ngrep that it’s only asking the root servers, but not the IP

    Configuration error?

    • Aa…oh! Christoph, I think you’ve hit a bug, mate. 🙂

      I’ve been using under /etc/ndjbdns/servers/, even with 1.05.6, and it works fine for me.

      I emptied servers/roots and created with

      $ echo “” > servers/

      set DEBUG_LEVEL=3 in dnscache.conf and restarted service.

      Upon looking at system logs, it looks like the server fails to read the first character from

      query 3 1
      tx 0 1

      As a temporary solution, please try:

      $ echo ”″ > servers/

      Notice a space(‘ ‘) before 192 above, it could be any character.

      Thank you so much for reporting it.

      • Thanks for picking up the unmaintained sources of DJB.

        Well, you emptied roots and found a bug,. But with me it is somewhat different.
        I want to have an actual roots file and yet if a host of is asked
        I want the DNS to aks an IP I configured in this file.
        But this is not happening. The root servers are asked if I run ‘dig @‘, but not

      • Yep-yep, emptying roots was just an experiment to confirm my doubt. I’ve been using along with roots for years now. Just that my – – has multiple servers listed, rather than just one. I think the single server entry is what hit the bug.

        Please try:

        $ echo -e “\n192.168.1.125” > servers/

        Please let me know how it goes. I’m working on fixing this issue.

        Thanks so much.

  2. Thank you for your help.
    The work-around with the introductive newline _does_ work.

    But now some of the root servers are asked plus the configured IP.
    It works, but I think it should only be asking the configured IP of our local authoritative nameserver.

    Also for some reason the domain mydomain.local does not work. Here only one root server is asked and not the configured nameserver.
    Perhaps because the TLD is not valid in the outside world?


    • Addendum:

      I experimented further and found out that alwas the root servers are queried first. And then (as a last resort?) the configured nameserver ip for the domain in servers/ is queried.

      • Yep, resolvers send (>1) parallel requests to TLD and other known servers. Amongst all TLD servers, few(2-3) are picked at a time for each request.

        Thanks so much!

    • Ah, nice to know it worked! cool!! 🙂

      Yes, resolvers generally send (>1) parallel requests to TLD or other known servers for a given domain name. That is normal behaviour.

      About mydomain.local, I don’t clearly understand the issue.

      Thank you.

      • I think it’s a misunderstanding.

        If I configure a file like servers/ with an IP of “” then this should be considered the authoritative nameserver for all queries for .
        There is no need to ask any of the root servers at all.

        I just tried: The original DJB sources do it this way.

        So the problem is those extra requests to the root servers. These shouldn’t happen at all.
        At least that’s my understanding of DNS.

      • I see. I have not changed the querying parts of the original DJB source, so it should work just the same. I’ll continue the investigation further.

        Thanks for sharing.

  3. Thank you Prasad.

    I’ve tested this source rpm for a while and as it worked as expected I was even brave enough to use it as a caching and authoritative nameserver for our little complany.

    No problems so far.
    Have a nice day.

    Greetings from Germany

    • That’s excellent! 🙂

      Thanks so much Christoph for testing and deploying the new package, really appreciate it. You made my day!!

      Thank you. 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s