Re: [musl] MAXNS should be increased

Re: [musl] MAXNS should be increased

[zhoujingqiang (A)]

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.
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.
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) <zhoujingqiang1@huawei.com>
抄送: musl@lists.openwall.com; liudongxu <liudongxu3@huawei.com>; Yulu(Brooklyn,RTOS) <yulu20@huawei.com>; Nixiaoming <nixiaoming@huawei.com>; Wangxu <wangxu72@huawei.com>; qiuguorui <qiuguorui1@huawei.com>; wangyunhe (A) <wangyunhe@huawei.com>
主题: 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

Re: [musl] MAXNS should be increased

[Joakim Sindholt]

On Wed, 11 Jan 2023 12:33:59 +0000, "zhoujingqiang (A)" <zhoujingqiang1@huawei.com> 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) <zhoujingqiang1@huawei.com>
> 抄送: musl@lists.openwall.com; liudongxu <liudongxu3@huawei.com>; Yulu(Brooklyn,RTOS) <yulu20@huawei.com>; Nixiaoming <nixiaoming@huawei.com>; Wangxu <wangxu72@huawei.com>; qiuguorui <qiuguorui1@huawei.com>; wangyunhe (A) <wangyunhe@huawei.com>
> 主题: 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
> 

Re: [musl] MAXNS should be increased

[Laurent Bercot]

>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 
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

Re: [musl] MAXNS should be increased

[Rich Felker]

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.

[musl] MAXNS should be increased

[zhoujingqiang (A)]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3552 bytes --]

Re: [musl] MAXNS should be increased

[Rich Felker]

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