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

Advertisements

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!! 🙂

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. 🙂

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. 🙂

New DJBDNS-1.05.6

Hello,

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 -> http://pjp.dgplug.org/ndjbdns/

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, 127.0.0.1.

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! 🙂