From Fedora Project Wiki
No edit summary
(forwarder notes)
Line 22: Line 22:


This DNSSEC-aware environment needs only two keys, for the root zone and the ISC DLV register. Both domain administrators follow RFC 5011 so keys will be updated automatically.
This DNSSEC-aware environment needs only two keys, for the root zone and the ISC DLV register. Both domain administrators follow RFC 5011 so keys will be updated automatically.
Paul: Note that for systems that are down a very long time, RFC-5011 might not work. There is talk of having some kind of zone where historical key data is presented to provide a secure upgrade path. It might make sense to have some check to disable dnssec when the installed keys are not in use (how to do that securely though?)
Paul: Note that I'm not sure if bind can dynamically update the forwarder used from the DHCP obtained settings, eg with some rndc command. I know unbound can using "unbound-control forwarder". This feature should really be done because otherwise every Fedora box will not use the global DNS caching infrastructure. Ideally, it will only become a full resolver without forwarder in the case that the forwarder does not support DNSSEC.
Different views also need to be handled (eg internal company view that's different from external view) so it is preferred to try and keep using the forwarder.


== Benefit to Fedora ==
== Benefit to Fedora ==

Revision as of 17:49, 25 January 2011

DNSSEC on workstations

Summary

The DNS Root zone was signed about 6 months ago and there are more than 20 TLDs signed via DNSSEC. Fedora will bring benefit of this important feature to the end users and their workstations.

Owner

  • Email: atkac at redhat dot com

Current status

  • Targeted release: Fedora 15
  • Last updated: 2011-Jan-25
  • Percentage of completion: 40%

Detailed Description

All major DNS servers in Fedora run with DNSSEC validation enabled by default since Fedora 11 so we have a lot of experience from server environment. When a DNS server is installed on the workstation, NetworkManager will the DNS server and update /etc/resolv.conf. After that all DNS traffic will go through DNSSEC-validating resolver.

This DNSSEC-aware environment needs only two keys, for the root zone and the ISC DLV register. Both domain administrators follow RFC 5011 so keys will be updated automatically.

Paul: Note that for systems that are down a very long time, RFC-5011 might not work. There is talk of having some kind of zone where historical key data is presented to provide a secure upgrade path. It might make sense to have some check to disable dnssec when the installed keys are not in use (how to do that securely though?)

Paul: Note that I'm not sure if bind can dynamically update the forwarder used from the DHCP obtained settings, eg with some rndc command. I know unbound can using "unbound-control forwarder". This feature should really be done because otherwise every Fedora box will not use the global DNS caching infrastructure. Ideally, it will only become a full resolver without forwarder in the case that the forwarder does not support DNSSEC.

Different views also need to be handled (eg internal company view that's different from external view) so it is preferred to try and keep using the forwarder.

Benefit to Fedora

All DNS traffic will be secured by DNSSEC

Scope

  • by default, DNS server should use only servers whose are available via DHCP. This information can be easily obtained via libnmserver library from NetworkManager. This library has already passed the review process.
  • NetworkManager already contains the plugin which can start the BIND DNS server and use it as a local resolver. This plugin needs to be improved a little.

How To Test

  • install NetworkManager and bind packages
  • check that DNS responses are validated (via dig utility)

User Experience

Although this change won't be visible to common users, users will be secured from various DNS spoofing and DNS cache-poisoning attacks.

Dependencies

  • bind - small patch (integration with the libnmserver library) is ready and tested but not submitted to upstream, yet
  • NetworkManager - little improvements for the bind plugin

Contingency Plan

Disable the BIND plugin by default and behavior will be same as in F14.

Documentation

Release Notes

NetworkManager now uses the BIND nameserver as a DNSSEC resolver. All received DNS responses are proved to be correct. If particular domain is signed and failed to validate then resolver returns SERFVAIL instead of invalidated response, which means something is wrong.

Comments and Discussion