From Fedora Project Wiki
No edit summary
Line 17: Line 17:
When DNSSEC is in use, after gathering the recursive nameservers, NetworkManager reconfigures a local unbound instance using dnssec-trigger. In this case the stub resolver should point to the local unbound instance and it should be instructed that the local unbound instance is not just an ordinary recursive name server '''but also a trusted DNSSEC validator'''.
When DNSSEC is in use, after gathering the recursive nameservers, NetworkManager reconfigures a local unbound instance using dnssec-trigger. In this case the stub resolver should point to the local unbound instance and it should be instructed that the local unbound instance is not just an ordinary recursive name server '''but also a trusted DNSSEC validator'''.


Problem: There is currently no way to distinguish ordinary recursive name servers and trusted DNSSEC validators in the stub resolver configuration.
=== Notes ===
 
Problem: There is currently no way to distinguish ordinary recursive name servers and trusted DNSSEC validators in the stub resolver configuration, see later.


== DNSSEC requirements on the stub resolver ==
== DNSSEC requirements on the stub resolver ==
Line 65: Line 67:
We have an experimental solution that relies on a separate <code>resolv-secure.conf</code> file. As opposed to <code>/etc/resolv.conf</code> typically containing the list of recursive name servers, <code>resolv-secure.conf</code> contains a list of trusted DNSSEC validators in form of validating DNSSEC servers. The list typically includes a single DNSSEC validator which is running on the local host.
We have an experimental solution that relies on a separate <code>resolv-secure.conf</code> file. As opposed to <code>/etc/resolv.conf</code> typically containing the list of recursive name servers, <code>resolv-secure.conf</code> contains a list of trusted DNSSEC validators in form of validating DNSSEC servers. The list typically includes a single DNSSEC validator which is running on the local host.


Advantages:
==== Advantages ====


* The file can be separately protected using mandatory access control. The whole stub resolver configuration is protected.
* The file can be separately protected using mandatory access control. The whole stub resolver configuration is protected.
Line 74: Line 76:
Use a special  
Use a special  


Risks:
==== Risks ====


* The configuration file could not be protected by mandatory access control while at the same time allowing tools to write a <code>/etc/resolv.conf</code> configuration when not using DNSSEC.
* The configuration file could not be protected by mandatory access control while at the same time allowing tools to write a <code>/etc/resolv.conf</code> configuration when not using DNSSEC.


=== Alternative solution: <code>option secure-dns</code> ===
=== Alternative solution: <code>option secure-dns</code> ===
Line 84: Line 86:
Mark <code>/etc/resolv.conf</code> configuration as ''secure'' when providing the list of secure DNSSEC validators.
Mark <code>/etc/resolv.conf</code> configuration as ''secure'' when providing the list of secure DNSSEC validators.


Risks:
==== Risks ====


* An existing tool might rewrite the list of name servers and keep the unknown options including <code>option secure-dns</code>.
* An existing tool might rewrite the list of name servers and keep the unknown options including <code>option secure-dns</code>.


=== Alternative solution: <code>option insecure-dns</code> ===
=== Alternative solution: <code>option insecure-dns</code> ===
Line 92: Line 94:
Mark <code>/etc/resolv.conf</code> configuration explicitly as ''insecure'' unless providing the list of secure DNSSEC validators.
Mark <code>/etc/resolv.conf</code> configuration explicitly as ''insecure'' unless providing the list of secure DNSSEC validators.


Risks:
==== Risks ====


* Existing <code>/etc/resolv.conf</code> files would be wrongly considered secure for DNSSEC validation.
* Existing <code>/etc/resolv.conf</code> files would be wrongly considered secure for DNSSEC validation.
* Existing tools would generate such files.
* Existing tools would generate such files.


=== ....To be processed.... ===
== FAQ ==
 
> Nothing prevents Network Manager from maintaining a list of
> trusted DNS servers
 
In a non-DNSSEC setup, NetworkManager gathers list of recursive
name servers (not trusted validators) and writes them to
'/etc/resolv.conf' so the resolver can do its job.
 
In a DNSSEC setup, NetworkManager gathers the very same list of recursive
name servers, (through dnssec-trigger) configures the local trusted DNSSEC
validator (unbound) and (without our fix) writes 'nameserver 127.0.0.1'
to '/etc/resolv.conf'.
 
In none of the two most common cases above there is any list of trusted DNS
servers to be maintained.
 
> the user has entered by hand, and using those
> instead of what is provided via DHCP.


NetworkManager accepts the list of recursive name servers (whether from the
=== Why is it wrong to implicitly trust the AD flag from recursive name servers ===
user or from DHCP), not the trusted validators. Instead in
NetworkManager/dnssec-trigger setups, the trusted validator is always
'127.0.0.1'.


> Your focus appears to be to fix an unfixable situation,
AD flag is how a validating name server informs the requester that the returned DNS data have been successfully validated using the DNSSEC mechanism.


It may appear so but it definitely isn't. See the definition of goals
There is a huge difference between using an untrusted recursive name server to retrieve DNS data
at the top of this mail. And we already have an experimental working
and using an untrusted DNSSEC validator. DNSSEC '''works well with untrusted
solution that works in line with the goals.
recursive name servers''' but its '''security is jeopardized by using them as
DNSSEC validators'''. Applications may attribute additional trust to the validated data especially when they contain security keys for TLS, SSH and other authenticated protocols.


> you are already on an untrusted network.
Trusting a random DNSSEC validator is like trusting a random security certificate.


There is a huge difference between using an untrusted recursive name server
=== Does DNSSEC work on untrusted or public networks? ===
and using an untrusted DNSSEC validator. DNSSEC works great with untrusted
recursive name servers but its security is jeopardized by *using them as
DNSSEC validators*.


> If anything you need an API to
Yes. There is no such concept as trusted or untrusted network in DNSSEC. The confusion comes from the distinction between a recursive name server (used by the system to retrieve DNS data) and a DNSSEC validator (which is typically a validating name server running on the local host).
> describe the network trust level e.g. Can I trust the results from
> DNS? This way applications will know if the results they have from
> any interface are safe.


For DNSSEC, all we need is to never implicitly use recursive name servers
For DNSSEC, all we need is to never implicitly use recursive name servers
as trusted DNSSEC validators. In my opinion, the best way to implement that
as trusted DNSSEC validators. In our opinion, the preferred way to implement that
is to avoid passing security information from ordinary recursive name
is to avoid passing security information from ordinary recursive name
servers (not configured as trusted DNSSEC validators).
servers (not configured as trusted DNSSEC validators).


> Until such an API exists I concede that a /etc/resolv.conf option,
=== Does NetworkManager need to keep track of trusted DNSSEC validators ===
> say `insecure-dns` could be created to remove all security information
> from DNS queries.
 
It is still wrong to use recursive name servers as trusted DNSSEC validators
by default.
 
> This way if Network Manager knows it is in a "public"
> network
 
This has nothing to do with public networks. It is wrong to use recursive name
servers as trusted DNSSEC validators unless explicitly stated.
 
Using a local name server as trusted DNSSEC validator is on the same level as
using a local HTTPS proxy without checking any certificates.
 
> it will set `option insecure-dns` in /etc/resolve.conf.
>
> > Of course this is just one way to do it. But I chose it for both ease of
> > implementation which is obvious from the submitted patch, and for its
> > inherent advantages described above. On the other hand, I will be happy
> > to learn about a better solution that will address the same potential
> > issues my patch addresses.
>
> The better solution is a higher level API for determining if you can
> trust the network,
 
No, because DNSSEC doesn't have the concept of trusting a network at all.
 
== FAQ ==
 
=== Does DNSSEC distinguish trusted and untrusted networks? ===


No. There is no such concept as trusted or untrusted network in DNSSEC. The confusion comes from the distinction between a recursive name server (used by the system to retrieve DNS data) and a DNSSEC validator (which is typically a validating name serveru running on the local host).
No. When working with dnssec-trigger, NetworkManager only needs to keep track of learnt and configured recursive name servers. The list of trusted DNSSEC validators always contains a single unbound instance running on the local host.


== TODO ==
== TODO ==


Some terms might need to be improved, especially ''recursive name server'' doesn't really say what we want to say which is a name server that is used by the system to gather necessary DNS data.
Some terms might need to be improved, especially ''recursive name server'' doesn't really say what we want to say which is a name server that is used by the system to gather necessary DNS data.

Revision as of 11:17, 15 June 2015

Configuration requirements

The main network configuration tool is NetworkManager. When using DNSSEC it is combined with dnssec-trigger via a script shipped in the dnssec-trigger package.

Common operations

With or without DNSSEC, NetworkManager gathers the list of recursive name servers from DHCP and/or configuration. The purpose of those name servers is to answer DNS queries including those for DNSSEC records. Those name servers are not meant to be trusted for anything else than attempting to answer the queries and especially not for performing DNSSEC validation.

Without DNSSEC

When DNSSEC is not in use, the easiest way to handle the list of name servers is to put them into /etc/resolv.conf so that the stub resolver can do its job.

As /etc/resolv.conf doesn't support advanced configuration, it is often useful to instead configure a local recursive DNS server (e.g dnsmasq or unbound) with the name server list and point the stub resolver to the local host using /etc/resolv.conf.

With DNSSEC

When DNSSEC is in use, after gathering the recursive nameservers, NetworkManager reconfigures a local unbound instance using dnssec-trigger. In this case the stub resolver should point to the local unbound instance and it should be instructed that the local unbound instance is not just an ordinary recursive name server but also a trusted DNSSEC validator.

Notes

Problem: There is currently no way to distinguish ordinary recursive name servers and trusted DNSSEC validators in the stub resolver configuration, see later.

DNSSEC requirements on the stub resolver

Glossary

Recursive name server – DNS server used by the system to gather DNS data

Trusted validator – DNS server used by the system to verify DNSSEC signatures

Expected behavior

Hi,

Those distribution policies have been correct for ages. Before DNSSEC was created, noone would question them.

We were looking for a solution where:

1) Application or security library can trust the data from glibc resolver including security information.

2) Resolver can provide unauthenticated DNS data when in non-DNSSEC mode and the list of recursive name servers is configured by a system administrator or an automated tool.

3) Resolver can provide autenticated DNS data when in DNSSEC mode andthe list of trusted resolvers is provided by the system administrator (rarely) or by an automated tool (in most cases giving just 127.0.0.1).

The most important thing is that the application never receives autenticated data that were only verified by an ordinary recursive server. That would mean an implicit trust in an unauthorized and unexpected DNSSEC validator.

Note that a recursive name server is typically a host on the local network announced by DHCP while a trusted validator is typically the local machine which itself is talking to a recursive name server.

Current status

The current implementation in glibc doesn't achieve the goals stated above and doesn't prevent the security problem of implicitly using foreign recursive name servers as trusted DNSSEC validators.

We have an experimental implementation using '/etc/resolv-secure.conf' that solves the problem. I'm looking forward to see any alternatives. The issue has been holding back DNSSEC deployment for long and might cause a lot of damage.

Solution: Separate file where all DNS servers are DNSSEC validators

We have an experimental solution that relies on a separate resolv-secure.conf file. As opposed to /etc/resolv.conf typically containing the list of recursive name servers, resolv-secure.conf contains a list of trusted DNSSEC validators in form of validating DNSSEC servers. The list typically includes a single DNSSEC validator which is running on the local host.

Advantages

  • The file can be separately protected using mandatory access control. The whole stub resolver configuration is protected.
  • The syntax is identical to /etc/resolv.conf. On a DNSSEC enabled system, /etc/resolv.conf can be just a symlink to /etc/resolv.conf.

Alternative solution: option secure-nameserver

Use a special

Risks

  • The configuration file could not be protected by mandatory access control while at the same time allowing tools to write a /etc/resolv.conf configuration when not using DNSSEC.

Alternative solution: option secure-dns

(or for example option trust-dnssec-validation)

Mark /etc/resolv.conf configuration as secure when providing the list of secure DNSSEC validators.

Risks

  • An existing tool might rewrite the list of name servers and keep the unknown options including option secure-dns.

Alternative solution: option insecure-dns

Mark /etc/resolv.conf configuration explicitly as insecure unless providing the list of secure DNSSEC validators.

Risks

  • Existing /etc/resolv.conf files would be wrongly considered secure for DNSSEC validation.
  • Existing tools would generate such files.

FAQ

Why is it wrong to implicitly trust the AD flag from recursive name servers

AD flag is how a validating name server informs the requester that the returned DNS data have been successfully validated using the DNSSEC mechanism.

There is a huge difference between using an untrusted recursive name server to retrieve DNS data and using an untrusted DNSSEC validator. DNSSEC works well with untrusted recursive name servers but its security is jeopardized by using them as DNSSEC validators. Applications may attribute additional trust to the validated data especially when they contain security keys for TLS, SSH and other authenticated protocols.

Trusting a random DNSSEC validator is like trusting a random security certificate.

Does DNSSEC work on untrusted or public networks?

Yes. There is no such concept as trusted or untrusted network in DNSSEC. The confusion comes from the distinction between a recursive name server (used by the system to retrieve DNS data) and a DNSSEC validator (which is typically a validating name server running on the local host).

For DNSSEC, all we need is to never implicitly use recursive name servers as trusted DNSSEC validators. In our opinion, the preferred way to implement that is to avoid passing security information from ordinary recursive name servers (not configured as trusted DNSSEC validators).

Does NetworkManager need to keep track of trusted DNSSEC validators

No. When working with dnssec-trigger, NetworkManager only needs to keep track of learnt and configured recursive name servers. The list of trusted DNSSEC validators always contains a single unbound instance running on the local host.

TODO

Some terms might need to be improved, especially recursive name server doesn't really say what we want to say which is a name server that is used by the system to gather necessary DNS data.

Retrieved from "https://fedoraproject.org/w/index.php?title=Networking/NameResolution/DNSSEC/Design&oldid=415578"