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=HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26048 invoked from network); 10 Jan 2023 06:59:32 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 10 Jan 2023 06:59:32 -0000 Received: (qmail 11495 invoked by uid 550); 10 Jan 2023 06:59:28 -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 30257 invoked from network); 10 Jan 2023 00:57:48 -0000 From: "zhoujingqiang (A)" To: "musl@lists.openwall.com" CC: liudongxu , "Yulu(Brooklyn,RTOS)" , Nixiaoming , Wangxu , qiuguorui , "wangyunhe (A)" Thread-Topic: MAXNS should be increased Thread-Index: AdkkjbKF10xNcPQpQOiDk/Hd6TTHjw== Date: Tue, 10 Jan 2023 00:57:34 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.109.132] Content-Type: multipart/alternative; boundary="_000_c11794d249654abd8f81cdeef6bc0330huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [musl] MAXNS should be increased --_000_c11794d249654abd8f81cdeef6bc0330huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Currently, MAXNS is set to 3 which limits the number of nameserver. It is n= ot enough to meet most people's requirements for private DNS servers. In my= scenario, my client needs to access the networks of six companies. Each co= mpany provides active/standby servers to obtain private domain names. Three= DNS servers are far from enough. Expect to increase MAXNS to 12 Glibc has similar open bug[1]. The concern is that changing MAXNS would cau= se an ABI break. Musl does not have this problem since __res_state is stub. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D998211 I am not subscribed and want to be Cc'd on replies, thanks. --_000_c11794d249654abd8f81cdeef6bc0330huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Currently, MAXNS is set to 3 which limits the number of nameserv= er. It is not enough to meet most people's requirements for private DNS ser= vers. In my scenario, my client needs to access the networks of six companies. Each company provides active/standby= servers to obtain private domain names. Three DNS servers are far from eno= ugh.

 

Expect to increase MAXNS to 12

 

Glibc has similar open bug[1]. The concern is that changing MAXN= S would cause an ABI break. Musl does not have this problem since __res_sta= te is stub.

[1]: http= s://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D998211

 

I am not subscribed and want to be Cc’d on replies, thanks= .

--_000_c11794d249654abd8f81cdeef6bc0330huaweicom_-- 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 28111 invoked from network); 10 Jan 2023 16:29:02 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 10 Jan 2023 16:29:02 -0000 Received: (qmail 9247 invoked by uid 550); 10 Jan 2023 16:28: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 8191 invoked from network); 10 Jan 2023 16:28:57 -0000 Date: Tue, 10 Jan 2023 11:28:45 -0500 From: Rich Felker To: "zhoujingqiang (A)" Cc: "musl@lists.openwall.com" , liudongxu , "Yulu(Brooklyn,RTOS)" , Nixiaoming , Wangxu , qiuguorui , "wangyunhe (A)" Message-ID: <20230110162844.GE4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] MAXNS should be increased On Tue, Jan 10, 2023 at 12:57:34AM +0000, zhoujingqiang (A) wrote: > Hello, > > Currently, MAXNS is set to 3 which limits the number of nameserver. > It is not enough to meet most people's requirements for private DNS > servers. In my scenario, my client needs to access the networks of > six companies. Each company provides active/standby servers to > obtain private domain names. Three DNS servers are far from enough. > > Expect to increase MAXNS to 12 > > Glibc has similar open bug[1]. The concern is that changing MAXNS > would cause an ABI break. Musl does not have this problem since > __res_state is stub. > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998211 > > I am not subscribed and want to be Cc'd on replies, thanks. Multiple nameservers in resolv.conf are not a means to do unioning of conflicting DNS namespaces. They're expected to be purely redundant with non-conflicting (i.e. if one doesn't know about something another does, it has to ignore the query or ServFail, not NxDomain or NODATA it) records. If you need unioning of distinct spaces using custom rules for resolving conflicts, you need a special nameserver running on localhost or somewhere else you control that performs this logic. Rich 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 21026 invoked from network); 11 Jan 2023 13:16:42 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 11 Jan 2023 13:16:42 -0000 Received: (qmail 17679 invoked by uid 550); 11 Jan 2023 13:14:01 -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 16051 invoked from network); 11 Jan 2023 12:34:13 -0000 From: "zhoujingqiang (A)" To: Rich Felker CC: "musl@lists.openwall.com" , liudongxu , "Yulu(Brooklyn,RTOS)" , Nixiaoming , Wangxu , qiuguorui , "wangyunhe (A)" Thread-Topic: [musl] MAXNS should be increased Thread-Index: AdkluPVK10xNcPQpQOiDk/Hd6TTHjw== Date: Wed, 11 Jan 2023 12:33:59 +0000 Message-ID: <3a82362e2ce04f049042145c986f6da6@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.109.132] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [musl] MAXNS should be increased VGhhbmtzIGZvciByZXBseSwNCg0KSXQgaXMgbm90IGFkdmlzYWJsZSB0byB1c2UgbG9jYWxob3N0 IGFzIGEgRE5TIHNlcnZlciBpbiBlbWJlZGRlZCBkZXZpY2VzLiBJdCByZXF1aXJlcyBhIHJlc2lk ZW50IHByb2Nlc3MsIHdoaWNoIGNvbnN1bWVzIG1hbnkgbWVtb3J5IGFuZCBiYW5kd2lkdGguDQpX ZSBvbmx5IHByb3ZpZGUgZGV2aWNlcywgbm90IHNlcnZlcnMuIFNlcnZlcnMgYXJlIHByb3ZpZGVk IGJ5IGNhcnJpZXJzLiBXZSBjYW5ub3Qgd3JpdGUgYSBidWlsZC1pbiBzcGVjaWFsIHNlcnZlcnMg b24gcmVzb2x2LmNvbmYuDQpPdXIgZGV2aWNlcyBuZWVkIHRvIGJlIHNvbGQgdG8gY2FycmllcnMg YXJvdW5kIHRoZSB3b3JsZC4gVGhlcmUgYXJlIG1hbnkgc21hbGwgY2FycmllcnMuIFRoZXkgaGF2 ZSB0aGVpciBvd24gZG9tYWluIG5hbWVzLCB3aGljaCBhcmUgbm9uLWNvbmZsaWN0aW5nIGJ1dCB1 bmlxdWUuIEluIHRoaXMgY2FzZSwgaW5jcmVhc2luZyB0aGUgTUFYTlMgbGltaXQgaXMgdGhlIHNp bXBsZXN0IGFuZCBtb3N0IGVmZmljaWVudCB3YXkuSSB0aGluayByYWlzaW5nIE1BWE5TIHdvbid0 IGh1cnQgYW55dGhpbmcuDQpPciBpcyBpdCBwb3NzaWJsZSB0byBwcm92aWRlIGFuIGludGVyZmFj ZSBmb3IgTUFYTlMgdG8gYmUgZHluYW1pY2FsbHkgY29uZmlndXJhYmxlIHRvIG1ha2UgaXQgbW9y ZSBmbGV4aWJsZT8NCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IFJpY2ggRmVsa2VyIFtt YWlsdG86ZGFsaWFzQGxpYmMub3JnXSANCreiy83KsbzkOiAyMDIzxOox1MIxMcjVIDA6MjkNCsrV vP7IyzogemhvdWppbmdxaWFuZyAoQSkgPHpob3VqaW5ncWlhbmcxQGh1YXdlaS5jb20+DQqzrcvN OiBtdXNsQGxpc3RzLm9wZW53YWxsLmNvbTsgbGl1ZG9uZ3h1IDxsaXVkb25neHUzQGh1YXdlaS5j b20+OyBZdWx1KEJyb29rbHluLFJUT1MpIDx5dWx1MjBAaHVhd2VpLmNvbT47IE5peGlhb21pbmcg PG5peGlhb21pbmdAaHVhd2VpLmNvbT47IFdhbmd4dSA8d2FuZ3h1NzJAaHVhd2VpLmNvbT47IHFp dWd1b3J1aSA8cWl1Z3VvcnVpMUBodWF3ZWkuY29tPjsgd2FuZ3l1bmhlIChBKSA8d2FuZ3l1bmhl QGh1YXdlaS5jb20+DQrW98ziOiBSZTogW211c2xdIE1BWE5TIHNob3VsZCBiZSBpbmNyZWFzZWQN Cg0KT24gVHVlLCBKYW4gMTAsIDIwMjMgYXQgMTI6NTc6MzRBTSArMDAwMCwgemhvdWppbmdxaWFu ZyAoQSkgd3JvdGU6DQo+IEhlbGxvLA0KPiANCj4gQ3VycmVudGx5LCBNQVhOUyBpcyBzZXQgdG8g MyB3aGljaCBsaW1pdHMgdGhlIG51bWJlciBvZiBuYW1lc2VydmVyLg0KPiBJdCBpcyBub3QgZW5v dWdoIHRvIG1lZXQgbW9zdCBwZW9wbGUncyByZXF1aXJlbWVudHMgZm9yIHByaXZhdGUgRE5TIA0K PiBzZXJ2ZXJzLiBJbiBteSBzY2VuYXJpbywgbXkgY2xpZW50IG5lZWRzIHRvIGFjY2VzcyB0aGUg bmV0d29ya3Mgb2Ygc2l4IA0KPiBjb21wYW5pZXMuIEVhY2ggY29tcGFueSBwcm92aWRlcyBhY3Rp dmUvc3RhbmRieSBzZXJ2ZXJzIHRvIG9idGFpbiANCj4gcHJpdmF0ZSBkb21haW4gbmFtZXMuIFRo cmVlIEROUyBzZXJ2ZXJzIGFyZSBmYXIgZnJvbSBlbm91Z2guDQo+IA0KPiBFeHBlY3QgdG8gaW5j cmVhc2UgTUFYTlMgdG8gMTINCj4gDQo+IEdsaWJjIGhhcyBzaW1pbGFyIG9wZW4gYnVnWzFdLiBU aGUgY29uY2VybiBpcyB0aGF0IGNoYW5naW5nIE1BWE5TIA0KPiB3b3VsZCBjYXVzZSBhbiBBQkkg YnJlYWsuIE11c2wgZG9lcyBub3QgaGF2ZSB0aGlzIHByb2JsZW0gc2luY2UgDQo+IF9fcmVzX3N0 YXRlIGlzIHN0dWIuDQo+IFsxXTogaHR0cHM6Ly9idWdzLmRlYmlhbi5vcmcvY2dpLWJpbi9idWdy ZXBvcnQuY2dpP2J1Zz05OTgyMTENCj4gDQo+IEkgYW0gbm90IHN1YnNjcmliZWQgYW5kIHdhbnQg dG8gYmUgQ2MnZCBvbiByZXBsaWVzLCB0aGFua3MuDQoNCk11bHRpcGxlIG5hbWVzZXJ2ZXJzIGlu IHJlc29sdi5jb25mIGFyZSBub3QgYSBtZWFucyB0byBkbyB1bmlvbmluZyBvZiBjb25mbGljdGlu ZyBETlMgbmFtZXNwYWNlcy4gVGhleSdyZSBleHBlY3RlZCB0byBiZSBwdXJlbHkgcmVkdW5kYW50 IHdpdGggbm9uLWNvbmZsaWN0aW5nIChpLmUuIGlmIG9uZSBkb2Vzbid0IGtub3cgYWJvdXQgc29t ZXRoaW5nIGFub3RoZXIgZG9lcywgaXQgaGFzIHRvIGlnbm9yZSB0aGUgcXVlcnkgb3IgU2VydkZh aWwsIG5vdCBOeERvbWFpbiBvciBOT0RBVEENCml0KSByZWNvcmRzLiBJZiB5b3UgbmVlZCB1bmlv bmluZyBvZiBkaXN0aW5jdCBzcGFjZXMgdXNpbmcgY3VzdG9tIHJ1bGVzIGZvciByZXNvbHZpbmcg Y29uZmxpY3RzLCB5b3UgbmVlZCBhIHNwZWNpYWwgbmFtZXNlcnZlciBydW5uaW5nIG9uIGxvY2Fs aG9zdCBvciBzb21ld2hlcmUgZWxzZSB5b3UgY29udHJvbCB0aGF0IHBlcmZvcm1zIHRoaXMgbG9n aWMuDQoNClJpY2gNCg0K 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=-4.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4791 invoked from network); 11 Jan 2023 15:38:23 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 11 Jan 2023 15:38:23 -0000 Received: (qmail 21748 invoked by uid 550); 11 Jan 2023 15:38:19 -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 21704 invoked from network); 11 Jan 2023 15:38:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zhasha.com; s=wirbelwind; t=1673451483; bh=ysYKz6ipdGkQXou3ABUGD17MuX52OsTB6FyYDtWbZS0=; h=Date:From:To:Subject:In-Reply-To:References; b=kQoDMbTeJD7sV8sXNqhebrvTceIXoOQV3VzTEMDaYWPCDjc/412WUzVR0qu9oYpYY JHzkkBwqyyI0raMo543Tc+OM6LCY7WZXTaqxOQ2VT6UuXnhNpH6m2F/Jaw3jqMrnQh T49oVFybv0/eA5tsD9PQW4UpBIwyOagx9+ytgTYk= Date: Wed, 11 Jan 2023 16:38:02 +0100 From: Joakim Sindholt To: musl@lists.openwall.com Message-Id: <20230111163802.415537961294f06006481144@zhasha.com> In-Reply-To: <3a82362e2ce04f049042145c986f6da6@huawei.com> References: <3a82362e2ce04f049042145c986f6da6@huawei.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [musl] MAXNS should be increased On Wed, 11 Jan 2023 12:33:59 +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. Having made no effort whatsoever to keep a small footprint I have a caching dnsmasq running here that consumes a grand total of 160kB of RAM. Furthermore, by virtue of it being specifically configurable, it uses significantly less bandwidth than always blasting 12 DNS servers concurrently. It feels like you've gotten hung up on the word "server" for no good reason here. > 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. That's almost guaranteed to be the least efficient way possible. > Or is it possible to provide an interface for MAXNS to be dynamically configurable to make it more flexible? > > -----邮件原件----- > 发件人: Rich Felker [mailto:dalias@libc.org] > 发送时间: 2023年1月11日 0:29 > 收件人: zhoujingqiang (A) > 抄送: musl@lists.openwall.com; liudongxu ; Yulu(Brooklyn,RTOS) ; Nixiaoming ; Wangxu ; qiuguorui ; wangyunhe (A) > 主题: Re: [musl] MAXNS should be increased > > On Tue, Jan 10, 2023 at 12:57:34AM +0000, zhoujingqiang (A) wrote: > > Hello, > > > > Currently, MAXNS is set to 3 which limits the number of nameserver. > > It is not enough to meet most people's requirements for private DNS > > servers. In my scenario, my client needs to access the networks of six > > companies. Each company provides active/standby servers to obtain > > private domain names. Three DNS servers are far from enough. > > > > Expect to increase MAXNS to 12 > > > > Glibc has similar open bug[1]. The concern is that changing MAXNS > > would cause an ABI break. Musl does not have this problem since > > __res_state is stub. > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998211 > > > > I am not subscribed and want to be Cc'd on replies, thanks. > > Multiple nameservers in resolv.conf are not a means to do unioning of conflicting DNS namespaces. They're expected to be purely redundant with non-conflicting (i.e. if one doesn't know about something another does, it has to ignore the query or ServFail, not NxDomain or NODATA > it) records. If you need unioning of distinct spaces using custom rules for resolving conflicts, you need a special nameserver running on localhost or somewhere else you control that performs this logic. > > Rich > 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 6580 invoked from network); 11 Jan 2023 15:54:12 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 11 Jan 2023 15:54:12 -0000 Received: (qmail 3408 invoked by uid 550); 11 Jan 2023 15:54:09 -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 3373 invoked from network); 11 Jan 2023 15:54:08 -0000 From: "Laurent Bercot" To: musl@lists.openwall.com Cc: liudongxu , "Yulu(Brooklyn,RTOS)" , Nixiaoming , Wangxu , qiuguorui , "wangyunhe (A)" Date: Wed, 11 Jan 2023 15:53:57 +0000 Message-Id: In-Reply-To: <3a82362e2ce04f049042145c986f6da6@huawei.com> References: <3a82362e2ce04f049042145c986f6da6@huawei.com> User-Agent: eM_Client/9.2.1222.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] MAXNS should be increased >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. >We only provide devices, not servers. Servers are provided by carriers. We = cannot write a build-in special servers on resolv.conf. That is, unfortunately, a common misconception - but a misconception nonetheless, and if your aim is to provide quality devices that will adequately serve your users, it would probably be a good idea to understand the protocols you're implementing, to understand simple orders of magnitude wrt resources used by software, and to follow correct practices that won't give incoherent results. A caching resolver (which you're calling "server", but DNS servers are an entirely different thing) can be very small, if chosen appropriately. The one I use on all my devices consumes 324 kB plus 2 MB that I choose to allocate as a cache (in order to save bandwidth). As another poster said, it could go as low as 160 kB. Resident processes are not an issue with good system engineering practices: they can be made reliable, and with proper choice of=20 software, they can use a pretty tiny amount of resources. If you wish, you can even configure your caching resolver to forward queries to the carrier's resolvers in all cases, ensuring your devices don't even have to perform the burden of DNS resolution themselves. I realize these basics of systems engineering may not be common knowledge to a company that is only [checks notes] the second largest telecommunication equipment manufacturer in the world. Since this is my area of expertise, I would be happy to help you on that subject. Please contact me privately on the listed e-mail address for business proposals. -- Laurent 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.