Re: [musl] Adding dns/resolver tests to libc-test

[Rich Felker <dalias@libc.org>]

On Wed, Sep 11, 2024 at 10:38:18PM +0200, Szabolcs Nagy wrote:
> * Ryan Ward <rwardd@outlook.com.au> [2024-09-09 14:46:22 +0000]:
> > > My intent was that you call enter_dns_test_ns from the test process
> > > itself, not from a separate wrapper to exec it. This is so you don't
> > > end up having a program in the tests dir that, when executed
> > > independently as root, clobbers the host system's resolv.conf or hosts
> > > file (which would be really really bad). By entering the namespace in
> > > the same process and testing for error, you can bail out before doing
> > > anything if the namespace setup failed. This also avoids the need to
> > > add extra control machinery to run the tests.
> > 
> > No problems, understood, I saw the exec call in the unshare-ns.c file 
> > and got confused. I have refactored the test attached, and added the 
> > unshare-ns.c file to the src/common/ directory in libc-test, and exposed
> > the enter_dns_test_ns method in the test.h header file. Is this an 
> > appropriate solution?
> 
> it's ok
> 
> > The attached res_query test tests for expected domain names, classes,
> > types and response data from given requests. I'm yet to implement TCP
> > or IPV6, and wanted to ask if v4/v6 should be in separate test files, 
> > as to ensure the test files aren't too long-winded. I've tried to structure
> > the test so it's as simple as specifying a domain name, and its expected RR 
> > data. The test just then iterates through the domains to test, the server returns
> > the hardcoded packets, and checks are performed.
> > 
> > Is this somewhat along the lines of what you are looking for?
> 
> i'm not yet sure if specifying static req - resp pairs
> will be enough. (e.g. an answer callback would be more
> flexible, so a series of add_stuff_to_answer(ctx, stuff)
> and then return make_answer(ctx) or similar to take
> care of large responses with many addresses or if some
> bits are set in unusual ways that could be spelled out
> instead of having to catch that in a long hex string)

I think a lot of valuable tests will be static answers, and probably
all of them *can be*. That's because, if you're testing the behavior
of the resolver interfaces with a particular input, there are
particular queries you expect it to make, and aside from query id,
they admit hard-coded answers.

The most interesting tests are probably things like safe handling of
malformed/malicious responses, which are necessarily hand-crafted, not
something that general-purpose code for constructing well-formed DNS
responses would ever emit.

Rich