[dns-operations] Looping wildcard CNAMEs can be an obstacle for DANE, (googledomains.com-hosted example)

[Jimmy Hess]

On Tue, Apr 17, 2018 at 8:56 AM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:

> some leave more of the work up to the client?  That is, when the qtype
> is not CNAME, and the answer section returned by a recursive resolver
> has just:
>         qname.example. IN CNAME cname.example.
> with rcode NOERROR, can one definitely conclude that "cname.example."
> has no data of the requested type?  And if the recursive resolver

You can conclude that there should be no data   for the lefthand name
(other than possibly a SIG,NXT, or KEY)

By definition a CNAME points the Alias to the target that is the  one
and only final
canonical name  for that alias.
Per

* RFC2181 10.1 -- "The DNS CNAME ('canonical name') record exists to
provide the canonical name  associated with an alias name.  There may
be only one such canonical name for any one alias. ...

An alias name (label of a CNAME record) may, if DNSSEC
is in use, have SIG, NXT, and KEY RRs, but may have no other data.
.. exactly one of the following is true:
     + one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs,
     + one or more records exist, none being CNAME records,
     + the name exists, but has no associated RRs of any type,
     + the name does not exist at all."


> exceeds its recursion limit (whatever that might be), the RCODE will
> be ServFail?  Which will typically also the case when it encounters
> an indirect loop (because there's no code to track the names already
> tried, just a recursion limit):

>         qname.example. IN CNAME cname.example.
>         cname.example. IN CNAME qname.example.

I believe in this example  both CNAMEs are invalid,   Or don't  have
the meaning you are suggesting,   since the alias of another CNAME
cannot be  target of a CNAME record  ---  the concept of a
"Loop" doesn't exist,

And also In that DNS software are specifically required to  suppress CNAME
processing on the target,  when evaluating the Target of a CNAME,  so

A CNAME  Can't be a "Loop",  again  RFC2181 10.1    "There may be only
one such canonical name for any one alias"
AND    RFC 2065  2.3.5

"Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along
with CNAME RRs,
(2) suppress CNAME processing on retrieval of these types as well as
on retrieval of the type CNAME

... This is a change from the previous DNS standard which prohibited
any other RR
type at a node where a CNAME RR was present.
"

That was a change from  the Original RFC1034  3.6.2   Which indicates

"Of course, by the robustness principle, domain software should not fail when
presented with CNAME chains or loops; CNAME chains should be followed
and CNAME loops signalled as an error."


The  Update from the RFC 2065 standard  effectively has a MUST
requirement that   CNAME
Chains and Loops not be evaluated.


> But for a direct loop:
>
>         qname.example. IN CNAME cname.example.
>         cname.example. IN CNAME cname.example.
>
> some resolvers might return NOERROR, and leave the loop
> (and perhaps an effective NODATA result) to be detected by
> the client?
>
> --
>         Viktor.
--
-JH