From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 68B9C2D713 for ; Wed, 11 Sep 2024 23:34:09 +0200 (CEST) Received: (qmail 13462 invoked by uid 550); 11 Sep 2024 21:34:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13412 invoked from network); 11 Sep 2024 21:34:03 -0000 Date: Wed, 11 Sep 2024 17:33:55 -0400 From: Rich Felker To: Ryan Ward , "musl@lists.openwall.com" Message-ID: <20240911213354.GX10433@brightrain.aerifal.cx> References: <20240818093842.GD3766212@port70.net> <20240827213435.GG10433@brightrain.aerifal.cx> <20240911203818.GC2724612@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240911203818.GC2724612@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Adding dns/resolver tests to libc-test On Wed, Sep 11, 2024 at 10:38:18PM +0200, Szabolcs Nagy wrote: > * Ryan Ward [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