From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16303 invoked from network); 6 Dec 2022 05:20:01 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 6 Dec 2022 05:20:01 -0000 Received: (qmail 10048 invoked by uid 550); 6 Dec 2022 05:19:58 -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 10013 invoked from network); 6 Dec 2022 05:19:57 -0000 Date: Tue, 6 Dec 2022 01:19:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=macdermid.ca; s=key1; t=1670303985; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PiC1Ki0XYMQwdp9sR2FWJpntYx21Mh++LEDdU95/wKk=; b=hJa0oKDp0W++a+ymL+/kQMHqoqFShY+IYTZoHN5dv4vN9sUF3bZxarpGQUSEB28E/oQjU+ CoTILYHfa0mhL9LvkNQqe++U3MCkb7pCQH3TDg/gVIx8sQi/kFSl8x/2jXLbGpyeVRMLGs z6aLkY2rHJK67HM9h8RPXvwAoOe40W0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kenny MacDermid To: musl@lists.openwall.com Message-ID: <20221206051939.hsse4vffoaeb3uqu@localhost> References: <20221204040254.pfd3bqjztfw4vrue@localhost> <20221204054559.GB23755@voyager> <20221204153132.GV29905@brightrain.aerifal.cx> <20221204230410.bf52c3xjs44xhgfo@localhost> <20221205132604.GW29905@brightrain.aerifal.cx> <20221205201151.f6vr3hvi62x2lvwv@localhost> <20221205232506.3d0c68df.quinq@fifth.space> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221205232506.3d0c68df.quinq@fifth.space> X-Migadu-Flow: FLOW_OUT Subject: Re: [musl] lookup_name issue with search domains On Mon, Dec 05, 2022 at 11:25:06PM +0100, Quentin Rameau wrote: > Hi Kenny, > > > The API that's in question is called `gethostbyname*`. It's not > > getTXT, or getMX or anything like that. When calling that I don't > > care if a name exists, I care if a host exists. As such I expect the > > API to only look at host records (and possibly dnssec that protect > > them). I wouldn't really care if there was 10 odd new record types, > > if there's no host records then there's no host at that name. > > Indeed, and that's what you get there. > The DNS server is telling you it's authoritative > (you'll get no better different answer from somebody else), > the name exists, but its without an (IPv4) address. The name exists, yes, but does the _host_ exist? > Searching ends there because the host was found by name, > and the server said it doesn't have an associated address. Except a host wasn't found, just the name. To put an example to it, please point to the host that is 'notahost.macdermid.ca'. There is a TXT record for that domain name, yet I don't see how that creates a host. > > So I guess it comes down to the question: Does this match a host? > > This matches a host, with no configured AF_INET address. That would only be the case if we considered every domain name a host. I haven't found anything that specifies that particular limitation on DNS. If anything it seems MX records would be a counter-example. Also from RFC 1034: >>> We should be able to use names to retrieve host addresses, mailbox >>> data, and other as yet undetermined information. All data >>> associated with a name is tagged with a type, and queries can be >>> limited to a single type. Note it doesn't say 'data associated with a host'. I hope you don't feel I'm just being pedantic here. I'm simply trying to explain how we see domains names differently, and why I don't understand this particular difference between libc implementations. To me I own a domain and can create records in that domain. If I happen to point some names at hosts using A/AAA records, great. If other names have TXT, MX, or some other record type, well I don't feel I've created a host-missing-an-A/AAAA. And maybe I'm wrong. Maybe other libc's should be following musl and for a name to exist automatically makes it a host (although in that case, would musl be being pedantic in not supporting cloudflare?). Either way hopefully you understand better why it's confusing to me, and why people are bitten by this decision.