CNAME resolution support for the recursor.

[marcus0x62]

This PR adds support for CNAME resolution to the recursor, along with a set of related changes:

1. A new extend_records method in crates/resolver/src/lookup.rs to facilitate appending the resolved CNAMES to the original Lookup result.
2. A change to the DNS LRU insert_records function to use the original query type when inserting a CNAME record, to facilitate later retrieval of the record.
3. Core CNAME lookup logic for the recursor and a configurable recursion depth limit (default: 12 nested lookups) to prevent lookup loops
4. CNAME-related tests for single CNAME queries, CNAME chain queries, and the recursion depth limit.

[justahero]

The e2e test suite fails to compile, for example Record::cname or Record::CNAME are not defined. The Record is the one defined in the dns-test package.

Maybe you missed something to commit?

[marcus0x62]

The e2e test suite fails to compile, for example Record::cname or Record::CNAME are not defined. The Record is the one defined in the dns-test package.

Maybe you missed something to commit?

No, there is a separate PR open to add the CNAME record. See PR #2338.

[bluejekyll]

Is it possible for us to reuse the logic here in the caching_client for this? There's a lot of annoying details with CNAME recursion and other record types that also need to be resolved like CNAME.

https://github.com/hickory-dns/hickory-dns/blob/main/crates/resolver/src/caching_client.rs#L336-L472

[marcus0x62]

@bluejekyll I've been looking into this today, and while I need to do some more research, the first challenge I see is I don't think the record caching behavior (bundling the entire cname chain as one cache entry with the TTL set to the smallest TTL from the chain) is going to be optimal for the recursor, where having the records from the chain cached individually and according to the individual record TTL would be valuable/more efficient. As one example, a lot of CDN intermediate records are generic and will be used across multiple domains.

Secondly, and while it isn't necessarily a "problem" for the recursor (in terms of not working,) the caching client CNAME implementation seems to be built around the idea that CNAME chains will be returned more or less complete and that encountering a partial CNAME chain is the exception to be handled at the end , whereas the recursor implementation is the opposite - it expects to not get the full chain and early in its loop kicks off a search for missing links.

[djc]

LGTM overall, some small suggestions.

[bluejekyll]

the caching client CNAME implementation seems to be built around the idea that CNAME chains will be returned more or less complete and that encountering a partial CNAME chain is the exception to be handled at the end

I wonder if we can create a method for doing this that would be reusable? The CachingClient implementation will issue additional requests if the chain is incomplete, fwiw. What I'm worried about is that we're going to have to maintain two different areas of code that will have nuances around CNAME, HTTPS, SVCB, etc, records. I'd love it if we could have that logic abstracted. If not part of this PR, maybe something in the future.

[marcus0x62]

I wonder if we can create a method for doing this that would be reusable? The CachingClient implementation will issue additional requests if the chain is incomplete, fwiw. What I'm worried about is that we're going to have to maintain two different areas of code that will have nuances around CNAME, HTTPS, SVCB, etc, records. I'd love it if we could have that logic abstracted. If not part of this PR, maybe something in the future.

I think that's doable, but I'd like to tackle it as a separate effort. Another thing that probably makes sense to unify is the DNSSEC post-processing we're doing in both places. The differences in caching behavior can probably be eliminated - it doesn't seem critical for the caching client to store the entire CNAME chain as a single record. The other big difference is the working copy of the response records at the time of CNAME resolution is in a DnsResponse on the caching client side and a LookupResult on the recursor side. I think that could be abstracted, or the CNAME resolution on the recursor side could be moved into lookup instead of resolve...