Update CNAME resolution

[tgreenx]

Purpose

This PR slightly updates the CNAME resolution of Engine's recursor. See the Changes section below.
Updated test scenarios are defined in zonemaster/zonemaster#1477.

Context

zonemaster/zonemaster#1477

Also fixes zonemaster/zonemaster#1505

Changes

• Zonemaster::Engine::Recursor::_resolve_cname() now returns undef when the CNAME resolution fails, along with new message tags: CNAME_UNRESOLVABLE (ERROR level) and CNAME_TO_NODATA (DEBUG level)
• Fix case-sensitiveness of CNAME records
• Update unit tests:
  • Move the content of scenario TOO-LONG-CNAME-CHAIN to a new scenario TOO-MANY-CNAME,
  • Update scenario TOO-LONG-CNAME-CHAIN to check for tag CNAME_CHAIN_TOO_LONG instead
  • Add scenario UNRESOLVABLE-CNAME
  • Add scenario CNAME-CHAIN-TO-NODATA

How to test this PR

Unit tests are updated and should pass.

[marc-vanderwal]

So far, so good.

[marc-vanderwal]

The CNAME_UNRESOLVABLE tag is output in some cases where the final query for a CNAME chain gives NODATA. That case can happen fairly frequently and should simply be treated like a negative response (i.e. NXDOMAIN), not like a resolution failure (as if we had gotten SERVFAIL).

I’d suggest a different name for that tag. How about CNAME_TO_NODATA?

[matsduf]

I’d suggest a different name for that tag. How about CNAME_TO_NODATA?

It think that is a good suggestion. Should there be another tag, CNAME_TO_NXDOMAIN?

For me CNAME_UNRESOLVABLE sounds like we cannot resolve the CNAME record.

[marc-vanderwal]

Yes, a CNAME_TO_NXDOMAIN might make sense too.

In any case, I don’t think the ERROR level is appropriate for these tags because they do not indicate a problem so severe that the zone is unresolvable.

[matsduf]

@tgreenx, will you fix the conflict?

[tgreenx]

@tgreenx, will you fix the conflict?

@matsduf @marc-vanderwal done, please re-review.

[tgreenx]

I’d suggest a different name for that tag. How about CNAME_TO_NODATA?

Added.

I’d suggest a different name for that tag. How about CNAME_TO_NODATA?

It think that is a good suggestion. Should there be another tag, CNAME_TO_NXDOMAIN?

Not needed, NXDOMAIN responses are already handled by the calling method (_recurse()).

There’s a subtle bug that I missed when reviewing. I’ll propose a change.

[matsduf]

I am not sure what you mean. All members of an RRset has always the same owner name. Is the following what you mean?

Suggested change

	This message tag indicates that there is a loop in the CNAME RRset of the current response.
	This message tag indicates that there is a loop in the CNAME record, i.e. the target name is identical to the owner name.

[tgreenx]

No, rather that there is a loop in the CNAME chain from within a single DNS response, e.g.:

example.tld           CNAME   target1.example.tld
target1.example.tld   CNAME   example.tld

[matsduf]

Unclear. Is the following what you mean?

Suggested change

	This message tag indicates that the CNAME target has already been followed in a previous lookup.
	This message tag indicates that the target name of the last CNAME record in a chain is identical to a previous CNAME record in the same chain.

[tgreenx]

I guess yes, but specifically when doing additional CNAME lookups. So it is a loop too, but not from within a single response (i.e lookup) this time but another one, e.g:

Query 1 (example.tld) -> Response 1:

example.tld     CNAME   example.other

Query 2 (example.other) -> Response 2:

example.other   CNAME   example.tld

[matsduf]

Does this refer to the answer section? That it contains a CNAME record and another DNS record matching the QTYPE but not the CNAME target name?

[tgreenx]

Yes exactly.

[tgreenx]

@matsduf As discussed I've made another pass on the documentation, please re-review