On Wed, Nov 22, 2017 at 12:09:51PM +0000, Tony Finch wrote:

> > If the SOA lookup fails, then the domain is severely broken
> 
> No, it might just be private.

We are not using the same (mine is correct :-) definition of failure.
An NXDomain reply is not a lookup failure.  The security status of
the domain is available regardless of whether we get NoError with
some answers, NoError with no answers (aka NoData) or NXDomain.

A private sub-domain should return NXDomain on the public side of
the Internet, with that answer signed or not based on the security
status of the parent zone.  Having the query ServFail is where of
course you run into trouble.

My recommended algorithm for CAA probing is that any (really, as
in ServFail, ...) failed CAA probe be accompanied by an SOA probe
for the *same* domain.

If the SOA probe succeeds (including NXDomain), and is signed, then:

    * Signed NXDomain is sufficient to conclude that CAA does not
      exist either
    * Signed NODATA is sufficient to conclude that the zone is
      signed and CAA lookup failure must not be ignored.
    * Ditto for a signed SOA RRset.

If the SOA probe succeeds (including NXDomain), and is not signed,
then:

    * Unsigned NXDomain is sufficient to conclude (sans DNSSEC) 
      that CAA does not exist either.

    * Unsigned NODATA is sufficient to conclude that the zone
      is not signed and persistent CAA failure might eventually be
      ignored (sparing the domain owner the pain signal they need
      to take important corrective action, perhaps not a good idea).

    * Ditto for unsigned SOA RRset.

If the SOA lookup (really) fails, then the domain is broken.  Any
non-public sub-domains that want certificates, should not be broken
in this way.  Either appear in the public DNS, return NXDomain or
NODATA.  A wildcard CAA record might in fact be a good way to
present a non-public subtree to the outside world:

    internal.example.com. IN CAA ...
    *.internal.example.com. IN CAA ...

-- 
        Viktor.

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to