New DJBDNS

Hi,

Today, I present to you New DJBDNS. A brand New release of the DJBDNS.

    See N-DJBDNS

I never thought I’d write this, but it is with extreme pleasure that I invite you to try,

    # yum install ndjbdns
Yes! N-DJBDNS – is an official Fedora package…YAY!!! 🙂

A packaging exercise which began more than three years ago, has finally come to an end. When it was approved, I spent some time reading all the comments that were posted on this review request. The very first one from Ralf Corsepius said


   This package will need a lot of love to let it pass a review.

I knew it was going to be tough, everybody said that. But honestly, I never imagined three years. It feels awesome today! 🙂

Feels awesome, not only because it is over, but also because it’s the new beginning. Now I can focus on further development and renovation. There’s a long list of things yet to be done. For N-DJBDNS to be more useful, concise, independent and maintainable in the long run, in the near future it needs to,

  • Apply existing patches which are not yet included in the current source. This is going to be tricky, because the original patches were not created for the current source tree. It’s going to be a lot of manual work to apply them.
  • Write good user manuals and online documentation for each of the tools. It could be like an E-book, with one chapter dedicated to each tool.
  • To perform rigorous testing of the individual tools on Linux, *BSD platforms.
  • Format the sources for more readability and hacking comfort. This might sound mundane and boring, but in the long run, I think it is just as important as fixing a security bug. I’ve done close to 50/204 files so far. I could definitely use a little help here.
  • Remove redundant source files.

If you think you could help with any of these tasks, please drop me a mail. I would more than appreciate it and would be glad to work with you. There are many individual tasks which are very good for summer projects and assignments.

If you have any comments, suggestions or if you find any bug in the current release, please feel free to write to me or raise an issue on github. I’ll do my best to address such issues.

I hope you find it useful. 🙂

PS: My sincere thanks to Rahul, Satya, Kushal and Rakesh for all your help.

Advertisements

10 thoughts on “New DJBDNS

  1. There appear to be some issues with the tinydns-get and tinydns executables. In short, they do not return any values. The dnscache works great. I have not had time to debug the tinydns executable, but creating the data.cdb using the installed tools, and then running tinydns-get results in no return value. However, if I used a restored copy of the original djbdns tinydns-get, it works fine. The tinydns executable does not return any value, rendering it inoperative. It is, of course, possible I’ve made an error somewhere, but the lack of information return from tinydns-get makes me suspicious there is a problem with the executable. I have tried against both Fedora 16 & 17.

    I presume the error is in the cdb routines (which, I note, the Fedora group wanted as a stand alone library). I would be happy to work with you on further refining this ndjbdns package. In the interim, however, do you have validated test cases showing the functionality of tinydns and tinydns-get?

    1. tinydns looks for data & data.cdb files under /etc/ndjbdns directory, see /etc/ndjbdns/tinydns.conf.

      Please let me know if the problem persists, I would surely like to work with you on this. I have made a note to write test cases for tinydns settings.

      1. I am going from the assumption that the failure of tinydns-get to provide any information is replicated into tinydns itself. There could be different issues, of course.

        I have the data file in /etc/ndjbdns, and in that directory I converted it into the data.cdb. Therefore, both files are in /etc/ndjbdns.

        Executing the /usr/bin/tinydns-get in the /etc/ndjbdns fails to return any information:

        [root@juno ndjbdns]# /usr/bin/tinydns-get a juno.example.com
        1 juno.example.com:
        [root@juno ndjbdns]#

        However, using a copy of tinydns-get that I had from before (I compiled it directly from source from DJB a few years ago), results in the following:

        [root@juno ndjbdns]# ORG_DJB/tinydns-get a juno.example.com
        1 juno.example.com:
        105 bytes, 1+1+1+2 records, response, authoritative, noerror
        query: 1 juno.example.com
        answer: juno.example.com 86400 A 192.168.1.67
        authority: example.com 259200 NS dns.example.com
        additional: dns.example.com 259200 A 192.168.1.68
        additional: dns.example.com 259200 A 192.168.1.68
        [root@juno ndjbdns]#

        [root@juno ndjbdns]# pwd; ll
        /etc/ndjbdns
        total 56
        -rw-r–r–. 1 root root 1711 Sep 22 23:51 axfrdns.conf
        -rw-r–r–. 1 root root 1711 Mar 15 2012 axfrdns.conf.ORG
        -rw-r–r–. 1 root root 1666 Sep 22 23:53 data
        -rw-r–r–. 1 root root 6598 Sep 22 23:53 data.cdb
        -rw-r–r–. 1 root root 1601 Sep 22 23:52 dnscache.conf
        -rw-r–r–. 1 root root 1506 Mar 15 2012 dnscache.conf.ORG
        drwxr-xr-x. 2 root root 4096 Sep 23 00:00 env
        drwxr-xr-x. 2 root root 4096 Sep 22 23:54 ip
        -rw-r–r–. 1 root root 38 Sep 22 23:53 Makefile
        drwxr-xr-x. 2 root root 4096 Sep 24 18:17 ORG_DJB
        drwxr-xr-x. 2 root root 4096 Sep 23 17:35 servers
        -rw-r–r–. 1 root root 1565 Sep 24 18:18 tinydns.conf
        -rw-r–r–. 1 root root 1506 Mar 15 2012 tinydns.conf.ORG
        [root@juno ndjbdns]#

        Again, I might be doing something wrong, but it is suspicious that tinydns-get, which only parses the *.cdb file and provides an answer is not working from the ndjbdns installation at /usr/bin, but an old copy is parsing the file properly. The *.cdb was created using the /usr/bin/tinydns-data, and the format must be correct else the old version of tinydns-get would not respond properly.

        The data file is the one I was using until the upgrade to Fedora 17 over the weekend.

        I really appreciate the effort you have invested to package these programs, as well your time in replying.

      2. I should have mentioned that I am on 64-bit Fedora 17.

        I have traced the issue to the definition used in uint32.h. By updating this file, I can get a compile in the ndjbdns-1.05.4 directory unzipped from the source .rpm to execute with expected results.

        The ndjbdns source distribution for uint32.h has:

        typedef unsigned long uint32;

        The working definition for me (and as defined from djbdns when compiled from the djbdns-1.05.tar.gz from cr.yp.to) is:

        typedef unsigned int uint32;

        I have not traced why the size definition is problematic. However, clearly the extra 4 bytes in the ndjbdns uint32.h definition on x86-64 systems, at least for me, is creating an issue, and the default .rpm installation for the 64-bit system did not work.

        The change in uint32.h also resolves the issue with tinydns not providing a response.

        — ../../tmp2/ndjbdns-1.05.4/uint32.h 2012-02-28 06:25:57.000000000 -0700
        +++ uint32.h 2012-09-24 21:06:26.621539068 -0600
        @@ -1,7 +1,7 @@
        #ifndef UINT32_H
        #define UINT32_H

        -typedef unsigned long uint32;
        +typedef unsigned int uint32;

        extern void uint32_pack(char *,uint32);
        extern void uint32_pack_big(char *,uint32);

        With this change, and replacing the executables in /usr/bin, I now have the tinydns system properly responding.

  2. I managed not to mention that the definition of uint32 in uint32.h undoubtedly must be 4 bytes on either a 32-bit or 64-bit system, and the uint64 definition uint64.h must be 8 bytes. There is a note at http://cr.yp.to/cdb/cdb.txt that the file definition relies upon 4 byte positioning:

    Positions, lengths, and hash values are 32-bit quantities, stored in
    little-endian form in 4 bytes.

    I believe it will be necessary to add something to the ./configure script to properly adjust the uint32.h (and possibly the uint64.h) to the correct size based upon the CPU architecture.

    1. Hello Kevin,

      Wow! That’s fantastic investigation! I heartily applaud your efforts and interest!! 🙂

      Thank you so much for sharing your findings. I’ll update the source with your patch, try to make test scripts for the configurations and make a new release asap.

      Thanks so much!

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s