Features/DNSSEC on workstations

From FedoraProject

< Features(Difference between revisions)
Jump to: navigation, search
(Moving back to FeaturePageIncomplete, hope to see this one in F16 :))
Line 2: Line 2:
  
 
== Summary ==
 
== 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.
+
The DNS Root zone was signed in July 15, 2010 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 ==
 
== Owner ==
 
<!--This should link to your home wiki page so we know who you are-->
 
<!--This should link to your home wiki page so we know who you are-->
* Name: [[User:atkac | Adam Tkac]]
 
 
* Name: [[User:pwouters | Paul Wouters]]
 
* Name: [[User:pwouters | Paul Wouters]]
* Name: [[User:jgorig | Jan Gorig]]
+
* Name: [[User:atkac | Adam Tkac]]
  
 
<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
 
<!-- Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or  technical issues need to be resolved-->
Line 14: Line 13:
  
 
== Current status ==
 
== Current status ==
* Targeted release: [[Releases/16 | Fedora 16]]
+
* Targeted release: [[Releases/17 | Fedora 17]]
* Last updated: 2011-Mar-29
+
* Last updated: 2012-Jan-06
* Percentage of completion: 40%
+
* Percentage of completion: 75%
  
 
== Detailed Description ==
 
== Detailed Description ==
Line 25: Line 24:
 
However, we MUST use DHCP obtained caching DNS servers to not explode the amount of traffic send to authorative servers by end nodes. So we need to be able (via NetworkManager) to signal a new updated forwarder to use for the local DNS server. Currently, only unbound supports this and DNSSEC properly. bind does not support this yet. unbound can use "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. If we were to move forward with DNSSEC on workstations, then we would have to install unbound as the default DNS server for Fedora. This should probably be discussed with releng.
 
However, we MUST use DHCP obtained caching DNS servers to not explode the amount of traffic send to authorative servers by end nodes. So we need to be able (via NetworkManager) to signal a new updated forwarder to use for the local DNS server. Currently, only unbound supports this and DNSSEC properly. bind does not support this yet. unbound can use "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. If we were to move forward with DNSSEC on workstations, then we would have to install unbound as the default DNS server for Fedora. This should probably be discussed with releng.
  
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: This is not true. I don't think either ISC not the Root has committed to using RFC 5011. However, the rollovers will be
+
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: This is not true. I don't think either ISC not the Root has committed to using RFC 5011. However, the rollovers will be slow and announced far in advance, so we can anticipate and prepare for it. Fedora currently ships these keys with the unbound and bind packages. 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, but there are operation issues with that and Verisign/ICANN has not commited to this yet.
slow and announced far in advance, so we can anticipate and prepare for it. Fedora currently ships these keys with the unbound and bind packages.
+
 
+
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, but there are operation issues with that and Verisign/ICANN has not commited to this yet.
+
 
+
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, since an attacker could always make this check fail)
+
 
+
  
 
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 locallly DHCP obtaind DNS server as forwarder. But this might require the user to select a manual override depending on how the local organisation has setup their internal and external DNS(SEC) zones.
 
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 locallly DHCP obtaind DNS server as forwarder. But this might require the user to select a manual override depending on how the local organisation has setup their internal and external DNS(SEC) zones.
Line 39: Line 32:
  
 
== Scope ==
 
== 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.
+
* by default, DNS server should use only servers whose are available via DHCP. This information can be easily obtained from NetworkManager.
 
+
* two additional services will run on every machine - unbound (DNSSEC capable resolver) and dnssec-triggerd (helper which checks if DNSSEC works, informs unbound about resolv.conf changes and informs user if something goes wrong)
* 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 ==
 
== How To Test ==
* install NetworkManager and bind packages
+
* install NetworkManager and dnssec-trigger
 +
* start unbound and dnssec-trigger services
 
* check that DNS responses are validated (via dig utility)
 
* check that DNS responses are validated (via dig utility)
  
Line 51: Line 44:
  
 
== Dependencies ==
 
== Dependencies ==
* bind - small patch (integration with the libnmserver library) is ready and tested but not submitted to upstream, yet
+
* dnssec-trigger should be installed and enabled by default
* NetworkManager - little improvements for the bind plugin
+
  
 
== Contingency Plan ==
 
== Contingency Plan ==
Disable the BIND plugin by default and behavior will be same as in F14.
+
* don't install dnssec-trigger by default
  
 
== Documentation ==
 
== Documentation ==
* libnmserver (https://fedorahosted.org/libnmserver)
+
* dnssec-trigger: http://nlnetlabs.nl/projects/dnssec-trigger
* NetworkManager (http://projects.gnome.org/NetworkManager)
+
* unbound: http://unbound.net
  
 
== Release Notes ==
 
== 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.
+
All DNS traffic is now secured via DNSSEC (http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions). Two newly-run daemons allow this - unbound and dnssec-triggerd.
  
 
== Comments and Discussion ==
 
== Comments and Discussion ==

Revision as of 11:27, 6 January 2012

Contents

DNSSEC on workstations

Summary

The DNS Root zone was signed in July 15, 2010 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 17
  • Last updated: 2012-Jan-06
  • Percentage of completion: 75%

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.

There is a complex environment with NetworkManager and /etc/resolv.conf that handles updating. This could be simplified if especially if we run our own resolver by staying staticly pointed to 127.0.0.1.

However, we MUST use DHCP obtained caching DNS servers to not explode the amount of traffic send to authorative servers by end nodes. So we need to be able (via NetworkManager) to signal a new updated forwarder to use for the local DNS server. Currently, only unbound supports this and DNSSEC properly. bind does not support this yet. unbound can use "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. If we were to move forward with DNSSEC on workstations, then we would have to install unbound as the default DNS server for Fedora. This should probably be discussed with releng.

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: This is not true. I don't think either ISC not the Root has committed to using RFC 5011. However, the rollovers will be slow and announced far in advance, so we can anticipate and prepare for it. Fedora currently ships these keys with the unbound and bind packages. 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, but there are operation issues with that and Verisign/ICANN has not commited to this yet.

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 locallly DHCP obtaind DNS server as forwarder. But this might require the user to select a manual override depending on how the local organisation has setup their internal and external DNS(SEC) zones.

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 from NetworkManager.
  • two additional services will run on every machine - unbound (DNSSEC capable resolver) and dnssec-triggerd (helper which checks if DNSSEC works, informs unbound about resolv.conf changes and informs user if something goes wrong)

How To Test

  • install NetworkManager and dnssec-trigger
  • start unbound and dnssec-trigger services
  • 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

  • dnssec-trigger should be installed and enabled by default

Contingency Plan

  • don't install dnssec-trigger by default

Documentation

Release Notes

All DNS traffic is now secured via DNSSEC (http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions). Two newly-run daemons allow this - unbound and dnssec-triggerd.

Comments and Discussion