Local DNSSEC resolver and Fedora cloud

Ryan Brown rybrown at redhat.com
Thu Aug 13 16:04:09 UTC 2015


On 08/11/2015 02:05 PM, P J P wrote:
> Hello all,
> 
> As we know, Fedora-23 Alpha release has just been announced. Which
> means, most of the proposed features which are approved for F23 are
> in reasonably good shape for us to try out.
> 
> One of the proposed system wide change is to install and enable local
> DNSSEC validating resolver across Fedora variants.
> 
> -> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> 
> This features proposes to install unbound[1] DNSSEC resolver along
> with the dnssec-trigger[2] tool, which is used to dynamically
> configure the 'unbound' resolver. Upon successful setup, user would
> have the unbound[1] DNSSEC resolver listening on the 127.0.0.1:53
> address. And the '/etc/resolv.conf' would point to this server as the
> designated 'nameserver' for the system.

Conveniently, this came up at the DNSSEC session yesterday afternoon. I
won't speak for the whole group, but I'd be concerned about what cases
the resolver would be enabled for.

As a user for the cloud image (local virt, AWS) I don't think adding
unbound would be much of an improvement. For cloud image deployment
scenarios, if DNS security is of importance to my deployment, I can
enforce that external to the instance by running one (or several) DNSSEC
resolvers that can be shared between my whole fleet. In AWS, you can set
up your VPC to configure a custom resolver over DHCP, and there are
similar options in Azure/Rackspace/etc.

A 1:1 ratio of servers to DNS resolvers seems pretty wasteful to me,
especially in an environment where marginal performance increases cost
money. So I'd be against enabling a local DNSSEC resolver in the cloud
image.

For Atomic Host, I think it makes more sense to have a shared resolver.
In that case, the host's resolver can be shared by all the tenant
containers. Not only do you get to amortize the cost of running Unbound
across N containers on the host, but you get shared DNS caching as well.


tl;dr: please don't put it in the cloud image, but I think it makes
sense for Atomic Host.

> Both unbound[1] & dnssec-trigger[2] packages are available in Fedora
> since long. And the proposed feature solution is known to work well
> for majority of the users. Currently work is in progress to ensure
> that the proposed feature works seamlessly well across all variants
> and addresses all use-cases for the Fedora users.
> 
> 
> The feature has been approved for the upcoming F23 release; But we
> need affirmation from the individual working groups to install and
> enable this feature in the respective variants.
> 
> 
> -> https://bugzilla.redhat.com/show_bug.cgi?id=1203950
> 
> 
> The affirmation would enable us to include the 'dnssec-trigger' &
> 'unbound' packages in the respective Fedora kickstart files.
> 
> Could we please have your(cloud-WG) consent to enable this feature on
> the Fedora cloud variant?
> 
> 
> If you have any concerns/comments/suggestions please let us know
> here.
> 
> --
> 
> [1] https://unbound.net/ 
> [2] http://www.nlnetlabs.nl/projects/dnssec-trigger/
> [3] https://lists.fedoraproject.org/pipermail/cloud/2015-July/005590.html
>
> Thank you.
> 
> ---Regards -P J P http://feedmug.com 
> _______________________________________________ cloud mailing list 
> cloud at lists.fedoraproject.org 
> https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of
> Conduct: http://fedoraproject.org/code-of-conduct
> 

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.


More information about the cloud mailing list