Of chroot, time zone and glibc

A N-DJBDNS user reported an issue saying, “Timestamps logged by the DNS servers are off by one hour. Doesn’t N-DJBDNS account for Daylight Savings Time(DST)? Our time changed this week.”

I was puzzled. Because N-DJBDNS servers use system time zone by initialising the TZ environment variable with it. System time zone is identified by a file ‘/etc/localtime’. Often it is a symbolic link pointing to one of the binary data file under ‘/usr/share/zoneinfo/’. Standard <time.h> functions read from this file to perform their operation. Since N-DJBDNS servers are confined to the chroot(2) jail, they can not access ‘/etc/localtime’ and thus have to rely on the
POSIX TZ environment variable for the time zone definition.
        vsftpd: vsf_sysutil_tzset(void) -> ../vsftpd-3.0.2/sysutil.c
        postfix: -> http://www.postfix.org/postconf.5.html (search for “TZ”)

How does one set this TZ variable? The closest I could get was the tzset(3) standard API. Going by its name, one would expect it to set the time zone appropriately, so that applications continue to see correct times. But far from it, the API actually reads TZ variable if it is set or reads ‘/etc/localtime’ when TZ is not set and initialises three public variables:

        extern char *tzname[2];
        extern long timezone;
        extern int daylight;

Of these, ‘tzname’ array stores standard & dst time zone names(ex: EST/EDT), ‘timezone’ stores the standard time offset from UTC(ex: +5:30/-12:00) and ‘daylight’ acts as a boolean variable indicating whether current time zone follows DST rules during any time of the year or not at all. tzset(3) manual says ‘daylight’ has been obsolete for many years. Thus is not useful. A saving grace for the tzset(3) API is that its manual is quite elaborate about 3 formats of the TZ variable.

N-DJBDNS was using the standard time zone name from ‘tzname[2]’ array and standard time offset from ‘timezone’ variable to define the TZ environment variable in its “std offset” format as IST+5:30 OR NZST-12:00 etc. This is where the bug lies, TZ definition does not account for DST time changes.

But there is no standard method to appropriately define the TZ variable so that it accounts for Daylight Savings Time, as and when it is applicable. I discussed this issue with the upstream glibc developers. They also agreed that it’ll help to have an API to query system time zone definition. As per the discussion, three bugs have been filed against glibc, including an RFE for a new time zone API.

        BZ#1077902 -> [RFE] A new API to query time zone data from the tzdata files.
        BZ#1077377 -> tzset(3) incorrectly sets the ‘int daylight’ variable.
        BZ#1076794 -> tzset(3) incorrectly sets tzname[1] DST time zone name.

A basic patch too has been submitted for the new time zone API. If you are interested in contributing to glibc, please join the discussion at #glibc on irc.freenode.net and libc-help mailing list. These bugs are classic low hanging fruits for someone to start with. ๐Ÿ™‚

Btw, the N-DJBDNS issue is fixed here -> d77a7d6dd1a2.


New-DJBDNS: User comments


+-- On Thursday, 30 January 2014 6:10 PM, Timbo wrote --+
|First of all, can I say THANK YOU for making DJBDNS useful.
|I've always had to fight with it and seeing it pop up on EPEL
|in a useful rpm format that used service and chkconfig, etc
|really made my day.
|I'm basically converting all my servers from using my home-brew
|compiled djbdns to yours.
|Anyway, thanks again for all your great work.

Best email of the week! Thank you Tim!! ๐Ÿ™‚



I’m pleased to announce a yet another release of the New-DJBDNS. The latest version 1.05.8 is now available in source and RPM package format from its home page:

    at -> http://pjp.dgplug.org/ndjbdns/.

Both Fedora and EPEL updates have been pushed and shall be soon available via the stable repositories using Yum(8).

    # yum install ndjbdns

The major and rather important change has been made to the caching server dnscache’s logs. Now these logs are arranged in chronological order with timestamps and readily comprehensible information. Earlier, most of it was cryptic hexadecimal values and numbers.

It is extremely important to have meaningful logs in place along with the secure logging mechanisms. Especially in the light of the recent events like the SEA DNS attack on nytimes.com or little earlier Distributed DoS attack against Spamhaus.org DNS servers etc. When responding to such events, having meaningful logs in place is but instrumental. Because the logs can tell you about the origins of these requests, quantities and distribution patterns of such requests across multiple sources and continents. A lot many conclusive findings can be derived from carefully crafted logs. But the lack of them could just make the matters equally worse for the defenders.

I planned to include similar updates to the root server tinydns’s logs too, but that got delayed a little because of some travel and work. Other major changes include addition of a new root server to the global list, and a bug fix update to the logrotate(8) configuration file.

I hope you find it helpful. ๐Ÿ™‚

New DJBDNS-1.05.7


    # yum install ndjbdns-1.05.7

I feel happy to announce yet another release, version 1.05.7, of the New DJBDNS. This is by far the most complete release of the New DJBDNS. It fixes a major bug(BZ#913651) in dnscache resolver while reading domain specific server data. The fix adds a new debug option to validate the authoritative server data stored in the memory. It also includes couple of new features which enable DNS servers to listen on multiple interfaces, on multi-home machines, and respond from the same IP address to which the requests were sent: BZ#913667 & BZ#917580.

This was an interesting issue to fix. Linux follows something called Weak Host Model. In this, a host chooses to send response packet from an interface/address that is most appropriate to it, which may not be the one on which the request was received. This means the destination IP address in the request and source IP address of the response could be different. This ensures that clients would never receive response from the server, would time-out and resend their requests. I’m surprised that there is no hardware level switch or kernel boot parameter to enable/disable such behaviour. The behaviour seems fundamentally flawed.

Apart from these changes, release 1.05.7 includes last of the DJB tools: walldns server. I’m pleased to announce that with walldns server, release 1.05.7 officially concludes the packaging exercise of the djbdns. Tools that are not installed, for these are no longer useful are:

    noinst_PROGRAMS = dnscache-conf tinydns-conf pickdns pickdns-data \
                                pickdns-conf rbldns-conf walldns-conf axfrdns-conf dnsmx

I urge you to upgrade to this latest version and hope that you continue to find it valuable and useful in your set-up. Thanks to Mark Johnson, Simone Caronni, Christoph Grรถver for helping me with the reviews and testing of these new changes.

Thank you! ๐Ÿ™‚



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.