A Trust DNS based Recursor

[bluejekyll]

This is pretty rough right now, probably a lot of work to do, but it does work for some basic queries, for example:

cargo run --all-features --bin recurse -- --debug -n 192.5.5.241:53 -t A www.example.com.

need some cleanup on output, but this is the current result:

Recursing for www.example.com. A from hints
Success for query Lookup { query: Query { name: Name("www.example.com."), query_type: A, query_class: IN, mdns_unicast_response: false }, records: [Record { name_labels: Name("www.example.com."), rr_type: A, dns_class: IN, ttl: 86400, rdata: Some(A(93.184.216.34)), mdns_cache_flush: false }], valid_until: Instant { t: 808620694303584 } }
        www.example.com. 86400 IN A 93.184.216.34

I don't think this is ready for review yet, lots to cleanup.

fixes: #1440

[bluejekyll]

This now wired up end to end, using this branch to checkout, and run from the root of the project directory, the recursor can be tested with:

cargo run --all-features --bin trust-dns -- -p 8853 --zonedir tests/test-data/named_test_configs --config tests/test-data/named_test_configs/example_recursor.toml

And then I used the resolve command to test with:

resolve -n 127.0.0.1:8853 www.example.com

The first call timed out as the recursion took longer than the timeout in the resolve command, but the second worked as it was cached at that point:

Querying for www.example.com A from tcp:127.0.0.1:8853, udp:127.0.0.1:8853
Success for query name: www.example.com type: A class: IN
	www.example.com. 86400 IN A 93.184.216.34

[bluejekyll]

Sorry for the delay in landing this. I want to try and build some tests to help verify this code before we land it. Those are taking me a bit of time to get in place.

[bluejekyll]

@djc, I'd like to land this so that we can do a release. I've marked it as experimental since we have very little test coverage on the new recursor crate at the moment. I think the most controversial thing here is that we're exposing a few more things from the resolver to reuse for this, but those are very useful here.

Once this is passing I think it's ready to go.

[djc]

I've skimmed this and it mostly seems reasonable.

[djc]

Style: I've kind of soured on type aliases; in my experience they make the code harder to understand (because of more opaque types) at not much benefit (no isolation of the inner type).

[bluejekyll]

I'm not sure on this one. I agree in principle, the issue is that the type becomes a bit unwieldy with all the generics, and that can cause a readability problem as well.

[djc]

Why is this? I can see that it's nice to avoid the clone, but it seems like returning &SOA would make life easier for downstream users? What do we need out of the Record in callers?

[bluejekyll]

I think I needed all the fields of Record. I was thinking about introducing a new TypedRecord... not sure if nows a good time for that.

[bluejekyll]

@djc, I started working on resolving the issue here. I think it's going to take a new type, that I'll plan to call TypedRecord. This will take the form of TypedRecord<R: RecordData> which will also introduce a new trait RecordData that all the RData types will implement. To facilitate the reference form, I think we might also need a TypedRecordRef<'_, R>, which would carry a reference to the interior RecordData and Name.

So I'd like to merge this as is, and then follow up with a PR to introduce that type, which may be a bigger refactor.

[djc]

Makes sense! Is the idea that we're getting rid of the RData enum in favor of a trait-based (that is, open) API, or will we keep both?

[bluejekyll]

I think we'd keep both? We need something generic in the Record, and I like the known sizes of all the types. Otherwise we'd need to box the types I think... the enum is generic across them all, so I was thinking TypedRecord<RData> would be the generic version. You can convince me otherwise.

[djc]

Not sure if this is the best place for this discussion but would like to understand what problem TypedRecord and/or TypedRecordRef are supposed to solve.