No edit summary |
|||
| (21 intermediate revisions by 5 users not shown) | |||
| Line 2: | Line 2: | ||
== Summary == | == Summary == | ||
DNS Root zone | 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:pwouters | Paul Wouters]] | |||
* Name: [[User:atkac | Adam Tkac]] | * Name: [[User:atkac | Adam Tkac]] | ||
| Line 12: | Line 13: | ||
== Current status == | == Current status == | ||
* Targeted release: Fedora | * Targeted release: [[Releases/17 | Fedora 17]] | ||
* Last updated: | * Last updated: 2012-Mar-26 | ||
* Percentage of completion: | * Percentage of completion: 100% | ||
Note that all required packages are now in rawhide, f17 and f16 (yum install dnssec-trigger) but that we have decided to keep this feature "opt-in" for Fedora 17. | |||
For Fedora 18 we hope to to have better integration with network manager with less user interaction and more automatic hot spot handling. | |||
== Detailed Description == | == 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. | 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. | |||
A special "hot spot signon" option is available to temporarilly allow spoofed DNS to allow redirection to a captive portal. Once full access is gained, the user can select to enable full DNSSEC again, and a new probe of the network capabilities will be performed. | |||
unbound also offers a special feature of running DNS over TLS to a set of "trusted" DNS servers that support DNS over TLS. Although using DNS like this is extremely slow, it does provide a viable alternative in those networks that keep breaking/redirecting DNS traffic, even after captive portal signon. For Fedora to use this, some infrastructure would need to be setup to serve the Fedora community. Paul Wouters and NLnetlabs run such servers, but more would be needed if the entire Fedora community could be using this fallback. Note that security of that infrastructure is important, but that DNSSEC traffic cannot be tampered with. There is also an aspect of privacy involved with sending Fedora users to third party servers. Until the Fedora community has agreed to access third party servers, example entries in /etc/unbound/unbound.conf will be left commented out. | |||
== Benefit to Fedora == | == Benefit to Fedora == | ||
| Line 25: | Line 39: | ||
== Scope == | == Scope == | ||
* by default, DNS server should use only servers whose are available via DHCP. This information can be easily obtained | * 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 == | == How To Test == | ||
* install NetworkManager and | * 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 [http://wiki.linuxwall.info/doku.php/en:ressources:articles:unbound_dnssec dig utility] or via the dnssec validator plugin of firefox) | ||
== User Experience == | == User Experience == | ||
Although this change won't be visible to common users | Although this change won't be visible to common users, users will be secured from various DNS spoofing and DNS cache-poisoning attacks. | ||
== Dependencies == | == Dependencies == | ||
* | * dnssec-trigger should be installed and enabled by default | ||
== Contingency Plan == | == Contingency Plan == | ||
* don't install dnssec-trigger by default | |||
== Documentation == | == Documentation == | ||
* dnssec-trigger: http://nlnetlabs.nl/projects/dnssec-trigger | |||
* unbound: http://unbound.net | |||
== Release Notes == | == 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 == | == Comments and Discussion == | ||
| Line 56: | Line 67: | ||
[[Category: | [[Category:FeatureAcceptedF17]] | ||
<!-- When your feature page is completed and ready for review --> | <!-- When your feature page is completed and ready for review --> | ||
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --> | <!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler --> | ||
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--> | <!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete--> | ||
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --> | <!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process --> | ||
Latest revision as of 20:51, 10 April 2012
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
- Name: Paul Wouters
- Name: Adam Tkac
- Email: atkac at redhat dot com
Current status
- Targeted release: Fedora 17
- Last updated: 2012-Mar-26
- Percentage of completion: 100%
Note that all required packages are now in rawhide, f17 and f16 (yum install dnssec-trigger) but that we have decided to keep this feature "opt-in" for Fedora 17. For Fedora 18 we hope to to have better integration with network manager with less user interaction and more automatic hot spot handling.
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.
A special "hot spot signon" option is available to temporarilly allow spoofed DNS to allow redirection to a captive portal. Once full access is gained, the user can select to enable full DNSSEC again, and a new probe of the network capabilities will be performed.
unbound also offers a special feature of running DNS over TLS to a set of "trusted" DNS servers that support DNS over TLS. Although using DNS like this is extremely slow, it does provide a viable alternative in those networks that keep breaking/redirecting DNS traffic, even after captive portal signon. For Fedora to use this, some infrastructure would need to be setup to serve the Fedora community. Paul Wouters and NLnetlabs run such servers, but more would be needed if the entire Fedora community could be using this fallback. Note that security of that infrastructure is important, but that DNSSEC traffic cannot be tampered with. There is also an aspect of privacy involved with sending Fedora users to third party servers. Until the Fedora community has agreed to access third party servers, example entries in /etc/unbound/unbound.conf will be left commented out.
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 or via the dnssec validator plugin of firefox)
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
- dnssec-trigger: http://nlnetlabs.nl/projects/dnssec-trigger
- unbound: http://unbound.net
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.