Initial fuzzing support, and failing fuzz test case.

[ximon18]

See fuzz/README.md.

Uses NLnetLabs/domain#441.

[tertsdiepraam]

Looks good, but I suggest that we keep this unmerged until we can make this depend on the main branch of domain.

[ximon18]

Looks good, but I suggest that we keep this unmerged until we can make this depend on the main branch of domain.

It now depends on the main branch of domain.

[tertsdiepraam]

Revived! Maybe a controversial change is to make the stelline feature no longer optional, but that seemed like the easiest way to do this right now since cargo-fuzz doesn't do dev-dependencies. Another solution would be to have a stelline feature or something like that, but that makes testing less nice too.

[ximon18]

Revived! Maybe a controversial change is to make the stelline feature no longer optional, but that seemed like the easiest way to do this right now since cargo-fuzz doesn't do dev-dependencies. Another solution would be to have a stelline feature or something like that, but that makes testing less nice too.

@tertsdiepraam: I'm afraid I don't understand what is left to do here, the PR seems to work for me in its current form.

[tertsdiepraam]

@ximon18 this is the "controversial" change. If you agree with this then its fine with me to merge it.

[ximon18]

I see.

The fuzz binary uses FakeEnv which causes this problem.

Could another way be to impl Env for FuzzEnv where FuzzEnv doesn't use Stelline (and so wouldn't be suitable for running dnst update or dnst notify unless some non-Stelline based impl of Env::dgram() and Env::stub_resolver_from_confg() would be possible)?

[Philip-NLnetLabs]

I wonder if we should do ldns-testns. If so then we will get stelline as well.

[ximon18]

Are you referring to #56?

[Philip-NLnetLabs]

Yes. We may need to rethink the name and design for the dnst version. But it seems a useful feature.

[ximon18]

Interesting idea... :-)