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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 17579 invoked from network); 11 Jan 2023 17:18:50 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 11 Jan 2023 17:18:50 -0000 Received: (qmail 19458 invoked by uid 550); 11 Jan 2023 17:18:46 -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 18388 invoked from network); 11 Jan 2023 17:18:45 -0000 Date: Wed, 11 Jan 2023 12:18:33 -0500 From: Rich Felker To: "zhoujingqiang (A)" Cc: "musl@lists.openwall.com" , liudongxu , "Yulu(Brooklyn,RTOS)" , Nixiaoming , Wangxu , qiuguorui , "wangyunhe (A)" Message-ID: <20230111171832.GF4163@brightrain.aerifal.cx> References: <3a82362e2ce04f049042145c986f6da6@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a82362e2ce04f049042145c986f6da6@huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] MAXNS should be increased On Wed, Jan 11, 2023 at 12:33:59PM +0000, zhoujingqiang (A) wrote: > Thanks for reply, > > It is not advisable to use localhost as a DNS server in embedded > devices. It requires a resident process, which consumes many memory > and bandwidth. I hope you'll take the advice from others telling you why this isn't the case, but regardless, the problem here is that you're asking for something very different than what you actually want. You asked for a higher MAXNS, but what you want is for the stub resolver to do unioning for you. This is a much bigger request -- it's for policy functionality that doesn't have existing precedent to be added to libc. That's pretty much a hard no. > We only provide devices, not servers. Servers are provided by > carriers. We cannot write a build-in special servers on resolv.conf. > > Our devices need to be sold to carriers around the world. There are > many small carriers. They have their own domain names, which are > non-conflicting but unique. In this case, increasing the MAXNS limit > is the simplest and most efficient way.I think raising MAXNS won't > hurt anything. If any of them returns NxDomain for a query that a different one returns an answer for, they *are* conflicting. Only if they return the same answer or ServFail/timeout would they be non-conflicting. It's possible to setup non-conflicting private zones this way (with ServFail) but not common practice and I doubt it's what they've done.