[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240911213354.GX10433@brightrain.aerifal.cx>
Date: Wed, 11 Sep 2024 17:33:55 -0400
From: Rich Felker <dalias@...c.org>
To: Ryan Ward <rwardd@...look.com.au>,
"musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: Adding dns/resolver tests to libc-test
On Wed, Sep 11, 2024 at 10:38:18PM +0200, Szabolcs Nagy wrote:
> * Ryan Ward <rwardd@...look.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
