Path: csiph.com!xmission!news.alt.net!eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!usenet-its.stanford.edu!usenet.stanford.edu!not-for-mail From: Havard Eidnes Newsgroups: comp.protocols.dns.bind Subject: Re: Request for review of performance advice Date: Thu, 09 Jul 2020 22:25:05 +0200 (CEST) Lines: 48 Approved: bind-users@lists.isc.org Message-ID: References: <3A0A6DF0-828F-49A5-83DF-8118FD663522@isc.org> <20200709.222505.133339871625714092.he@uninett.no> NNTP-Posting-Host: lists.isc.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1594326318 712 149.20.1.60 (9 Jul 2020 20:25:18 GMT) X-Complaints-To: action@cs.stanford.edu Cc: bind-users@lists.isc.org To: vicky@isc.org Return-Path: X-Original-To: bind-users@lists.isc.org Delivered-To: bind-users@lists.isc.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uninett.no; s=he201803; t=1594326305; bh=HQUszlzEYQwW0nUaNr7z9F8sKaGmccuLN4QSJQJQnHk=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=SwMvWCD0EJ9zG0o3DVVwlSe127E55tpWSPxbcCOgyi2aATQf9Bo+9iBtAh1qZ67MR 7lxDDiFEaRVodlqsLo7rostQqgoeH+i2HtYk/LYA2UP4v40rZIM9OYEJZDLeNkN/ge aRMxBxGcMJfaFmWpnY2b9gi0wuFSIOvXA5tlkYSA= In-Reply-To: <3A0A6DF0-828F-49A5-83DF-8118FD663522@isc.org> X-Mailer: Mew version 6.8 on Emacs 26.3 X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS autolearn=disabled version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mx.pao1.isc.org X-BeenThere: bind-users@lists.isc.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: BIND Users Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <20200709.222505.133339871625714092.he@uninett.no> X-Mailman-Original-References: <3A0A6DF0-828F-49A5-83DF-8118FD663522@isc.org> Xref: csiph.com comp.protocols.dns.bind:15966 > OS settings and the system environment ... > 2e) Make sure your socket send buffers are big enough. (not > sure if this is obsolete advice, do we need to tell people how > to tell if their buffers are causing delays?) 2e#1) Make sure your UDP socket *receive* buffers are big enough. If on BSD, monitor for "dropped due to full socket buffers" count in "netstat -s" output, and tune accordingly. Note that this may be a symptom of mis-tuning of other parts of BIND, causing excessive CPU usage, which may contribute to this problem. = BTW, unbound has configuration options ("so-rcvbuf" / "so-sndbuf") to tune these for only the name server; when I earlier looked for something similar in BIND I could not find a corresponding option, so had to do a system-wide tuning via sysctl, which isn't ideal, but solved the problem in my case. > named Features > 3a) Minimize logging. Query logging is expensive (can cost you > 20% or more of your throughput) so don't do it unless you > are using the logs for something. Logging with dnstap is > lower impact, but still fairly expensive. Don't run in > debug mode unless necessary. 3a#1) Do not configure BIND with --enable-querytrace. It most probably doesn't do what you might think it does, and is a major drag on performance. = See above under the new "2e#1" for a possible symptom... > 4b) Set an appropriate MTU for your network. Ensure that your > network infrastructure supports EDNS and large UDP responses up > to 4096. Ensure that your network infrastructure allows transit > for and reassembly of fragmented UDP packets (these will be > large query responses if you are DNSSEC signing) Well, isn't the major goal of DNS Flag Day 2020 to eliminate fragmentation for various reasons (some of them security-related), and recommends to set EDNS buffer size to 1232 instead of letting it be the present default of BIND of 4096? Best regards, - H=E5vard