mailing list of musl libc
 help / color / mirror / code / Atom feed
From: "Laurent Bercot" <ska-dietlibc@skarnet.org>
To: musl@lists.openwall.com
Cc: 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>
Subject: Re: [musl] MAXNS should be increased
Date: Wed, 11 Jan 2023 15:53:57 +0000	[thread overview]
Message-ID: <em4b271d6e-afdb-441d-84f9-de7a3e92ed83@b45b7ef3.com> (raw)
In-Reply-To: <3a82362e2ce04f049042145c986f6da6@huawei.com>


>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


  parent reply	other threads:[~2023-01-11 15:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-11 12:33 zhoujingqiang (A)
2023-01-11 15:38 ` Joakim Sindholt
2023-01-11 15:53 ` Laurent Bercot [this message]
2023-01-11 17:18 ` Rich Felker
  -- strict thread matches above, loose matches on Subject: below --
2023-01-10  0:57 zhoujingqiang (A)
2023-01-10 16:28 ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=em4b271d6e-afdb-441d-84f9-de7a3e92ed83@b45b7ef3.com \
    --to=ska-dietlibc@skarnet.org \
    --cc=liudongxu3@huawei.com \
    --cc=musl@lists.openwall.com \
    --cc=nixiaoming@huawei.com \
    --cc=qiuguorui1@huawei.com \
    --cc=wangxu72@huawei.com \
    --cc=wangyunhe@huawei.com \
    --cc=yulu20@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).