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@xxxxxxxxxxxxxxxxxxxxxxx > 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. _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
