Local DNS resolver in Fedora

Hello,

This post is a call for action. It is to spread the word about a newly proposed system wide change in Fedora, to install a trusted local DNS resolver listening on 127.0.0.1:53. Please
see:
     -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
     -> https://www.piratepad.ca/p/dnssec-requisites-configurations

Domain Name System(DNS) is the ‘core’ internet infrastructure. It is an integral part of each computer system. Without it, we can not use the Internet as we do today. Yet in its current form, it is a fairly weak system. It can be exploited to disrupt services and compromise user’s privacy; Which makes it an easy target for the malicious mind. Especially with the backdrop of the increasingly snooping governments and service providers world wide. To mitigate this risk and to improve user experience, it is proposed to install a trusted DNS resolver in Fedora.

Being an integral part of each system, the proposed system wide change is bound to break existing work-flows and applications. For ex:

    This is gonna conflict a bit with docker, and other users of network namespaces,
      like systemd-nspawn. When docker runs, it picks up the current ‘/etc/resolv.conf’
      and puts it in the container, but the container itself runs in a network namespace,
      so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container,
      and not the host, so dns resolving in the container will not work.  [1]

We want to avoid any such breakage caused by the proposed local DNS resolver. Towards that end, we are collecting all the possible information about these use cases; So that we can duly fix the ensuing bugs well before time when the proposed system wide change goes live(Ie. F22). Aim is to build a robust, reliable and secure DNS solution. One which works out of the box without any user intervention.

The etherpad & wiki page above document the requisites and the new work-flow. If you think that the proposed change would break any application on Fedora or if you’ve feature requests for the new default DNS resolver(including NetworkManager), please edit the etherpad page or let me know about it. Alternatively, you could enable the local DNS resolver in your set-up, as described in the wiki page and submit bug reports if you encounter any.

    See -> https://tinyurl.com/fedora-dnssec-trigger-bugs

Your comments, suggestions, opinions about this topic are welcome too. Please help us by spreading this message to more and more users.

Thank you! :)

[1] https://lists.fedoraproject.org/pipermail/devel/2014-April/198706.html

Tagged with: ,
Posted in Uncategorized

New-DJBDNS 1.06

Hello..!!!

I’m extremely happy to announce, the release 1.06 of the New-DJBDNS is now available for general usage. New updates are pushed to Fedora repositories and shall soon be available via stable channels. It’s a landmark 10′th release of the project. :)

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

A major highlight of this release is the couple of security fixes for potential Denial of Service (DoS) flaws. One happens by a subtle hash collision attack, while the other is a result of excessive read(2) calls. It is highly recommended to upgrade your set-up to use 1.06 release. Nevertheless, CVE requests for these vulnerabilities were rejected on non-technical grounds.
See:
        -> http://www.openwall.com/lists/oss-security/2014/02/10/4
        -> http://www.openwall.com/lists/oss-security/2014/02/17/3

Apart from these issues, 1.06 release fixes an important time zone bug(discussed -> here) to account for the Daylight Savings Time(DST) and introduces new command line options to read from non-default configuration file. This will help to run multiple instances of servers with different configuration parameters. Thanks to Francisco M Biete for writing a patch to introduce new options and to Don Ky for reporting the time zone issue.

Another major highlight of this release is an excellent documentation contributed by Satya K. It was the last pending packaging goal set in the early days, now met! :)

        See -> http://pjp.dgplug.org/ndjbdns/document.html

If you find a bug or spot anything amiss, please let me know, I’ll fix it. With last of the initial goals met, this release truly marks an important milestone in the evolution of the New-DJBDNS. Many people have contributed, in various ways, to this progress & the growth of New-DJBDNS. I sincerely thank them all for the constant support and encouragement they have offered me. It’s bliss!

Now, it’s time to set new achievable goals. It’s time to define the new possibilities. One of the long-standing inherent drawback of the New-DJDBNS is its inability to communicate over IPv6. In the second spell of its development, I plan to rid New-DJBDNS of this very inability. Apart from this super goal, if you have suggestions, feature requests or patches that you’d like to see merged in New-DJBDNS, I’m all ears, please feel free to write to me.

Thank you! :)

Tagged with: ,
Posted in Uncategorized

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.
See:
        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.

Tagged with: ,
Posted in Uncategorized

New-DJBDNS: User comments

Hello,

+-- 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.
|
|Cheers,
|Tim.

Best email of the week! Thank you Tim!! :)

Tagged with: , ,
Posted in Uncategorized

New-DJBDNS 1.05.9

Hello,

I feel extremely happy to announce that a new release, version 1.05.9, of the N-DJBDNS is out and available for download

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

(For the uninitiated) N-DJBDNS is the brand new, totally revamped and renovated version of the djbdns. It has lots of great features which make it all worth it to give it a try. :)

This release includes three major features along with the numerous enhancements to the code base, which significantly improve the quality of the software. The three major features are

* Human readable logging support in the root server: continuing the changes which began in the last release, this release concludes the logging changes by unifying the two loggers, one of root servers’ & another of dnscache(8) resolver’s into one. Thus enabling consistent, human readable log structure and format across all servers. It greatly helps to remove redundant code base. It significantly eases the task of maintenance.

* Xinetd(8) and Systemd(1) support for axfrdns(8): The DNS zone transfer server axfrdns(8) was broken[#3], because it used to depend on the ‘tcpserver’ for listening on its behalf. This issue is fixed with the new configurations which enable the axfrdns(8) server to work with Xinetd(8) & Systemd(1) services. Thanks to Jason Clark & Edwin Eefting for helping with the comprehensive reviews and testing.

* DNS(or domain) Block List in dnscache(8): This I think is the most important feature of this release. DNS Block List is a list of domain names which are to be blocked by the resolver. Client requests querying for such domains are dropped by the server. This would add an additional layer of security for DNS clients and also help to reduce malicious traffic.

DNS block list is a ‘cdb’ database created using tinydns-data(1) tool. tinydns-data(1) creates the ‘cdb’ database from a ‘data’ file. List the malicious domain names in this ‘data’ file as generic domain records, one on each line, as:

    :bad.domain.com:284::::

Number ’284′ is not used, it can be any integer between 256..65535. tinydns-data(1) would create a ‘data.cdb’ database from this ‘data’ file. Rename ‘data.cdb’ to ‘dnsbl.cdb’, for that is the file read by dnscache(8) resolver.

    $ mv data.cdb dnsbl.cdb

dnscache(8) reads ‘dnsbl.cdb’ from its working($ROOT) directory defined in its configuration file. For starters, I created a domain list from the www.phishtank.com data set. Being a set of phishing URLs, the list has few false positives though.

    $ python -m json.tool online-valid.json | grep -i ‘”url”: “http’ –    \
         | cut -d’/’ -f3 | sort | uniq | awk -e ‘{ print “:”$0″:284::::”; }’ | tee data

Hope you find it helpful. :)

Tagged with: , ,
Posted in Uncategorized

One billion per day

Hello,

Recently one of India’s much loved entrepreneur, business leader, current bureaucrat and a prospective politician Mr Nandan Nilekani said – Only 30 million Indians pay taxes, that’s 3%. And we(India) need to involve more people into the game to achieve what he calls growth through inclusion. I was surprised to read it. It’s unbelievable.

I still can not seem to get over it. It feels unfair. Why am I dutifully paying taxes when 97% of India isn’t? I have been thinking and talking about it. Does it mean 97% of India earns less than Rs 2,00,000/year?(Those who earn less than Rs 2,00,000/year are exempted from paying income tax) That can not be true. So who are these people who earn money but don’t pay taxes?

   0. Corporate salaried employees pay taxes. That is sure.
   1. My maid, earns less than Rs 10,000/month, exempted from tax.
   2. Auto Rikshaw driver, Rs 500-1000/day, pay taxes? I don’t know.
   3. Paani puri & Chai vendor, Rs 500-1000/day, pay taxes? I don’t know.
   4. Grocer, earns taxable income, pay taxes? I don’t know.
   5. Vegetable vendor, earns taxable income, pay taxes? I don’t know.
   6. Business men & Freelance worker, taxable income, pay taxes? I don’t know.
   7. Professionals(priests,doctors,lawyers,actors), taxable income, pay taxes? I don’t know.
   8. Farmers, Brokers, Property owners, taxable income, pay taxes? I don’t know.

I was thinking about this to increase the number of tax payers from current 30 million to say 100 million, ie. 10%. Some improvement. But the more I think, the more it seems impossible to increase the number of tax payers. Because there is no reliable way to know how much these people really earn. We just have to take their word for it. Unless we route every money transaction through a government monitored payment gateway; Which is not happening, at least for now. And even if it was there, I’m sure people will find ways to beat it. So then how do we increase the number of tax payers? How do we involve more people into the game?? If we did, we could abolish the current unfair Income Tax regime which only involves 3% of the India’s population.

In the same article wherein Mr Nilekani quoted the above figure, he also mentioned that India today has more than 700 million mobile subscribers and some 150 million internet users. Let’s say, of these 700 million mobile users, 500 million make 1 call a day(let’s be conservative). If we attach a tax of Rs 1 per call, we get Rs 500 million in one day. According to this study, we currently have around 150 million cable TV subscribers. We are a family oriented nation; We watch TV with our family, right? Roughly 4 people watch TV together? If we attach a tax of Rs 1/head/day we get Rs 600 million per day. Similarly, nearly 75 million people travel every day in India. That includes Indian Railways + State Road Transport buses + City Metropolitan Transport(buses + Metro trains) + Air travellers. If we attach a minimum tax say Rs 4/head/trip we stand to collect around Rs 300 million in one day.

   + 500,000,000 calls/day    x  Rs 1/call   = Rs 500,000,000/day
   + 150,000,000    TV/day   x  Rs 4/day   = Rs 600,000,000/day
   + 075,000,000 travel/day  x  Rs 4/head = Rs 300,000,000/day

That’s collection of Rs 1.4 Billion per day. And the tax per head is hardly Rs 6/day, Rs 180/month, Rs 2160/head/year. I’m sure our able bankers and elite economists can figure out a scheme to balance out such a tax structure so that our phone/cable/travel bills don’t shoot up through the sky and we don’t feel the pinch on our wallet. Couple of years ago there was a talk of implementing a revised Income Tax scheme called – Direct Tax Code – I wonder what happened to that.


[1] http://cis-india.org/telecom/resources/cable-tv
[2] http://boocci.com/the-story-of-an-auto-rickshaws-in-chennai/
[3] https://en.wikipedia.org/wiki/List_of_countries_by_number_of_mobile_phones_in_use

Tagged with:
Posted in Uncategorized

New-DJBDNS-1.05.8

Hello,

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. :)

Tagged with: , ,
Posted in Uncategorized
Follow

Get every new post delivered to your Inbox.