[Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview

[Simo Sorce]

On Thu, 16 Oct 2014 21:55:39 +0200
Petr Spacek <pspacek at redhat.com> wrote:

> On 16.10.2014 21:32, Simo Sorce wrote:
> > On Thu, 16 Oct 2014 20:39:05 +0200
> > Martin Kosek <mkosek at redhat.com> wrote:
> >
> >> On 10/16/2014 08:01 PM, Petr Spacek wrote:
> >> ....
> >>>> 1)
> >>>>
> >>>> I'm not sure if failing on DNSSEC-disabled forwarders by default
> >>>> is a good idea. Perhaps there could be some auto-detection code?
> >>>> Something along the lines of:
> >>>>
> >>>>      if forwarders_support_dnssec:
> >>>>          if not options.no_dnssec_validation:
> >>>>              enable_dnssec_in_ipa()
> >>>>      else:
> >>>>          print "WARNING: DNSSEC will not be enabled"
> >>>
> >>> We have discussed this with Martin
> >>
> >> ... Martin Basti/Martin2... Given there are more Martins in the
> >> team, you should be more specific :-)
> >>
> >>> and the intent is to tell people that their
> >>> infrastructure is broken and has to be fixed - sooner is better.
> >>>
> >>> There is an option --no-dnssec-validation for people who like
> >>> broken infrastructure.
> >>
> >> Broken infrastructure is rather strong word for the situation when
> >> just DNSSEC is not configured (it may work for the customer
> >> otherwise). "Infrastructure does not follow most up to date
> >> standards" may be more precise.
> >>
> >>   From my POV, this may be too strict. People may already use
> >> ipa-server-install in their scripts and it suddenly requiring new
> >> option may be seen as breakage.
> >>
> >> So maybe it would be better to just print big fat warning including
> >> [yes|no] question to continue during ipa-server-install and just
> >> print warning in unattended mode (and disable DNSEC validation)
> >>
> >> We can always be more strict in next release. CCing Simo and Rob in
> >> case they have different opinions.
> >
> > My opinion is that DNSSEC is too new to make it required by default
> > in any way.
> Sure, the standard is only 9.5 years old (RFC 4033). With this course
> we will be stuck with insecure DNS forever, like with with SSL 3.0 :-)

It's newer than the IPv6 one IIRC :)

> > For the first release it should be completely optional and opt in.
> > Once we sort out the initial hurdles we can slowly add warnings and
> > what not and at some point in the future switch the defaults and
> > start complaining.
> I'm afraid that nobody will notice it if it is completely disabled ...

So be it.

> > We have to assume that most forwarders will be broken, so perhaps
> > the
> That is the reason why there is detection & warning.
> 
> Please note that 'fixing' the issue is typically just about adding
> line "dnssec-enabled yes;" to named.conf on the "broken" forwarder
> (which is default even in RHEL 6 BTW).
> 
> Biggest problem is to convince admin to add the line to the config
> file, it is not a technical problem.

You are assuming the forwarder is bind on RHEL, that's a bad
assumptions. Also the admin doing the FreeIPA install in many cases is
not a Network admin, so he may have no way to act on the DNS
configuration fast (or ever).

> > correct course of action if someone decides to try DNSSEC and the
> > forwarders do not support it is to give a fat warning and disable
> > DNSSEC for non-managed zones.
> 
> It is not possible to do DNSSEC validation only for part of the tree
> *unless you manually install trust anchors to validators*.

I know, but the FreeIPA DNS server can reach to root zone to do the
validation for it's own managed zones, if the trust path is completely
broken as root zones are unreachable w/o forwarders then we should just
disable DNSSEC completely with a big warning.

> Keep in mind that validator has to be able to build chain of trust
> from name-under-validation to nearest trust anchor, i.e. typically to
> DNS root.

See above.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York