From Fedora Project Wiki
No edit summary
Line 2: Line 2:


Applications that don't understand DNSSEC are transparently protected by the local validating resolver which reports name resolution failure whenever validation of a DNS record fails. On the other hand, applications that know about DNSSEC can distinguish validated DNS records from DNS records in unsigned zones. Such applications can use DNSSEC validated data for example to initiate TLS sessions. A TLS library can do that for the application.
Applications that don't understand DNSSEC are transparently protected by the local validating resolver which reports name resolution failure whenever validation of a DNS record fails. On the other hand, applications that know about DNSSEC can distinguish validated DNS records from DNS records in unsigned zones. Such applications can use DNSSEC validated data for example to initiate TLS sessions. A TLS library can do that for the application.
== How to test ==
For testing dnssec-trigger, we recommend using a fully updated Fedora 21, Fedora 22 or Rawhide.
<pre>
yum install dnssec-trigger
<pre>
Then either reboot or start dnssec-trigger manually.


== Manual configuration via Unbound ==
== Manual configuration via Unbound ==

Revision as of 13:27, 16 February 2015

DNS name resolution queries can be secured by DNSSEC to avoid various spoofing attacks. When a local validating DNS resolver is in use, all software can potentially benefit from local DNSSEC validation if the system is configured properly. The root zone provides a global trust anchor that in turn allows for validation of DNS records in signed zones. Other trust anchors can be configured to explicitly protect known DNS subtrees.

Applications that don't understand DNSSEC are transparently protected by the local validating resolver which reports name resolution failure whenever validation of a DNS record fails. On the other hand, applications that know about DNSSEC can distinguish validated DNS records from DNS records in unsigned zones. Such applications can use DNSSEC validated data for example to initiate TLS sessions. A TLS library can do that for the application.

How to test

For testing dnssec-trigger, we recommend using a fully updated Fedora 21, Fedora 22 or Rawhide.

yum install dnssec-trigger
<pre>

Then either reboot or start dnssec-trigger manually.

== Manual configuration via Unbound ==

TBD

=== Local zones ===

TBD

=== Global zone ===

TBD

== Using dnssec-trigger-control (for testing only) ==

<code>dnssec-trigger</code> configures <code>/etc/resolv.conf</code> to use a local unbound instance on <code>127.0.0.1</code> and Unbound to use a secure global zone with nameservers submitted through <code>dnssec-trigger-control</code> or, if those aren't suitable, using public nameservers run by Fedora or the upstream project.

It also performs captive portal (hotspot) detection and temporarily changes <code>/etc/resolv.conf</code> to include the nameservers of the local network directly. That unfortunately '''breaks the local zones''' used with any network interfaces including those that have nothing to do with the captive portal connection.

== NetworkManager integration ==

TBD

== Debugging ==

Show global configuration and connection zones configuration in unbound:

<pre>
$ unbound-control forward
$ unbound-control list_forwards

To check NetworkManager's view of the configuration, use:

$ nmcli connection show active
$ nmcli connection show active <id/uuid>

Documentation TODO

  • Adding search domains.
  • Common changes that people may wish to make such as the add_wifi_provided_zones
  • When caches are flushed and what triggers that.
  • How issues such as VPN provided name servers are handled.
  • How to restart the services correctly.