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 14833 invoked from network); 5 Dec 2022 20:12:12 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 5 Dec 2022 20:12:12 -0000 Received: (qmail 30485 invoked by uid 550); 5 Dec 2022 20:12:08 -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 30453 invoked from network); 5 Dec 2022 20:12:08 -0000 Date: Mon, 5 Dec 2022 16:11:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=macdermid.ca; s=key1; t=1670271116; 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=hrY+e0MlqQTsL/qyrrbHIuFdAdwt9dT7wTi2ehD/OP4=; b=5XcRC2+mrrTRXz1cVMv6QLHR+X0fhT0mGw4ipZCjfeULEd8uDkZvz4azME5oAM8mIMw2Ok fQe9oMjC/+7PFxqViGRCeBDY2DbNDObkzyHJuICSeD0Dv74APsbHXEX/EsJUzIvA+c6a/v 01kZdw4GXZDoHtPaKmEoyD9jGGnAR4o= 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: <20221205201151.f6vr3hvi62x2lvwv@localhost> References: <20221204040254.pfd3bqjztfw4vrue@localhost> <20221204054559.GB23755@voyager> <20221204153132.GV29905@brightrain.aerifal.cx> <20221204230410.bf52c3xjs44xhgfo@localhost> <20221205132604.GW29905@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221205132604.GW29905@brightrain.aerifal.cx> X-Migadu-Flow: FLOW_OUT Subject: Re: [musl] lookup_name issue with search domains On Mon, Dec 05, 2022 at 08:26:05AM -0500, Rich Felker wrote: > As an analogy, you could imagine a DNS provider adding some sort of > TXT records to every name in your zone. Nothing about DNS says they > can't -- these are valid records that can exist anywhere -- but they'd > be serving something different than what you asked them to. > > In this case, Cloudflare is effectively making *every possible* name > under your zone exist, but with no RRs defined for it unless you > provided some. This is contrary to your intent that names you didn't > define simply not exist. Thank you for all the information Rich. I'm in no way trying to be argumentative here, and am not claiming to be a DNS expert. I'm just trying to provide another view of the issue. In providing a different perspective I think the analogy is a good place to start. Let's say we take it a bit further and say it wasn't the DNS provider changing things. Say I added an MX record to a domain. 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. >From my understanding of what you're saying: if the query response doesn't contain error flags , it's indicating the name exists. That's fine, the name exists. That doesn't mean the host exists. The response that comes back has zero 'Answer RRs'. If searching should now stop because the host was found, what's it's address? Reading a Linux man page on `resolv.conf` it says of the "Search list for host-name lookup": >> Resolver queries having fewer than ndots dots (default is 1) in them >> will be attempted using each component of the search path in turn >> until a match is found. In the case where I have 3 search list entries, has a host match been found because the second domain has an MX record? It doesn't seem like it to me. >From a glance for empty answers in RFC1034 I see section 6.2.4 has: NAME=SRI-NIC.ARPA, QTYPE=NS This query could return without any error but the RFC says: >> The only difference between the response and the query is the AA and >> RESPONSE bits in the header. The interpretation of this response is >> that the server is authoritative for the name, and the name exists, >> but no RRs of type NS are present there. That sounds to me like what Cloudflare is doing. They're saying they're the authority for the name, and no A records exist. So I guess it comes down to the question: Does this match a host?