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

Viktor Dukhovni ietf-dane at dukhovni.org
Tue Apr 17 13:56:42 UTC 2018

> On Apr 17, 2018, at 8:55 AM, Tony Finch <dot at dotat.at> wrote:
>> The Postfix DNS layer does not look for direct (a -> a) loops and
>> recurses when the answer is a CNAME (in case the resolver did not
>> recurse all the way to the answer).
> That should be unnecessary - part of the point of a recursive server is it
> does the work for you :-) So if the server returns a loopy CNAME to a
> stub, it should look the same (and be treated the same) as a NOERROR /
> NODATA response - a CNAME chain that doesn't end with a record of the
> desired type.

Yes, I know.  On the list of things to discuss with Wietse, but can we
rely on all iterative resolvers to do "sufficient" recursion?  Or do
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
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.

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?


More information about the dns-operations mailing list