I dunno, at this rate someone's going to have to owe someone a beer or
something. :P
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John
> W. Blue
> Sent: Monday, 21 November 2016 5:24 PM
> To: bind-us...@isc.org
> Subject: Re: Test, please ignore
>
> Ignoring level
Which we can assume is the reason Evan raised the question in the first place.
Stuart
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Darcy
Kevin (FCA)
Sent: Wednesday, 19 April 2017 8:59 AM
To: bind-users@lists.isc.org
Subject: RE: BIND 9
Hi,
I've been able to get my hands on some rather nice servers with 2 x 12 core
Intel CPU's and was wondering if anybody had any decent tuning tips to get BIND
to respond at a faster rate.
I'm seeing that pretty much cpu count beyond a single die doesn't get any real
improvement. I understand
> -Original Message-
> From: Plhu [mailto:p...@seznam.cz]
> a few simple ideas to your tests:
> - have you inspected the per-thread CPU? Aren't some of the threads
> overloaded?
I've tested both the auto-calculated values (one thread per available core) and
explicitly overridden
> -Original Message-
> From: Mathew Ian Eis [mailto:mathew@nau.edu]
>
>
> Basically the math here is “large enough that you can queue up the
> 9X.XXXth percentile of traffic bursts without dropping them, but not so
> large that you waste processing time fiddling with the queue”.
Just some interesting investigation results. One of the URL's Matthew Ian Eis
linked to talked about using a tool called 'perf'. For the hell of it, I gave
it a shot.
Sure enough it tells some very interesting things.
When BIND was restricted to using a single NUMA node, the biggest call (to
2017 10:30 AM
To: bind-users@lists.isc.org
Cc: Browne, Stuart
Subject: [EXTERNAL] Re: Tuning suggestions for high-core-count Linux servers
360k qps is actually quite good… the best I have heard of until now on EL was
180k [1]. There, it was recommended to manually tune the number of subthreads
Ugh, let me try that again (apologies if you got the half-composed version).
> The lab uses Dell R430s running Fedora Core 23 with Intel X710 10GB NICs
> and each populated with a single Xeon E5-2680 v3 2.5 GHz 12-core CPU.
R630 chassis I believe, same NIC's, smaller processor
So, different tact today, namely the monitoring of '/proc/net/softnet_stat' to
try reduce potential errors on the interface.
End result: 517k qps.
Final changes for the day:
sysctl -w net.core.netdev_max_backlog=32768
sysctl -w net.core.netdev_budget=2700
/root/nic_balance.sh em1 0 2
Hi,
Just a quick question.
I've recently run in to another daemon (not associated with BIND) that
inherited its 'nofile' ulimit before dropping privileges and was wanting to
confirm that BIND doesn't work this way.
On some of our servers (zone distribution points) where lots of AXFR's (over
If the incoming query has already been parsed and it BIND instance now knows it
doesn't need to respond, it's already done all the work, so there's no point
not sending the response. To introduce something before the BIND instance in
userspace, then for every legitimate query you are
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Randy Bush
> Sent: Friday, 3 August 2018 6:08 AM
>
> >> ... are there that many folk doing tcp out there?
> > All name servers fall back to TCP when they receive truncated replies.
>
> we
Be wary of DNAME's; they can be quite limited.
Here's an example from our old system:
internal. 3600IN SOA mgmt1.mel.internal.local.
sysadmin.external.com.au. 2014051201 28800 14400 360 86400
internal. 3600IN NS mgmt1.mel.internal.local.
internal. 3600IN
Was adding in some new internal functionality and noted that the 'tsig-keygen'
tool doesn't give the ability to alter the keysize like dnssec-keygen does for
generating HMAC based tsig keys.
I also noticed that in 9.13, dnssec-keygen will no longer be able to generate
HMAC tsig's, so I'm
2018 3:40 PM
> To: Browne, Stuart
> Cc: bind-users@lists.isc.org
> Subject: Re: 'tsig-keygen' vs 'dnssec-keygen' - keysize
>
>
> > On 5 Sep 2018, at 2:50 pm, Browne, Stuart via bind-users us...@lists.isc.org> wrote:
> >
> > Was adding in some new internal fun
The kicker was probably this line:
Sep 6 15:44:40 ns3 audit: { write } for pid=15447 comm="named"
name="named.secroots" dev="dm-0" ino=135707451
scontext=system_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:etc_t:s0
tclass=file permissive=0
The SELinux context that BIND runs in on a
> -Original Message-
> From: Evan Hunt [mailto:e...@isc.org]
> Sent: Thursday, 6 September 2018 4:35 PM
> To: Browne, Stuart
> Cc: Mark Andrews; bind-users@lists.isc.org
> Subject: Re: 'tsig-keygen' vs 'dnssec-keygen' - keysize
>
> > Is there no crypt
How about a clear, direct example of using external service 'logrotate' (this
is from one of my redhat systems, but the same concept applies to
Ubuntu/Debian):
[be...@dns-nomnom1.den ~]$ cat /etc/logrotate.d/named
/var/log/named/*.log {
compress
create 0644 named named
daily
dateext
A number of places use a 'stealth' (or 'hidden') master as a bit of protection
from potential bad actors. It's a network domain barrier between the master
(usually on an internal-only network) from a public network with potential bad
actors.
For example, a dynamic update for a zone will
Assuming the slave can retrieve the SOA and zone, yup. It should just come
right back online.
Stuart
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
rohan.henry cwjamaica.com
Sent: Friday, 29 June 2018 8:48 AM
To: bind-users@lists.isc.org
Subject: Handling expired
It does depend somewhat on what you mean by concurrent sessions.
Do you mean incoming queries?
Do you mean incoming zone transfers?
Do you mean outgoing zone transfers?
Each is a different tunable.
Ultimately, system-wide file descriptor limits do come in to play, but the zone
transfers listed
> -Original Message-
> From: bind-users On Behalf Of Alex
> I'm leaning towards that, too. The problem persists even when using
> the provider's DNS servers. I thought for sure I'd see some verifiable
> info from other people having problems with cable, such as from
> dslreports, etc,
>From my reading of the error message and the zone data provided, they don't
>match.
The error is stating near db.fin line 17 that the label is 'hp4000.' (note the
full-stop); this doesn't appear to be the case with the pasted data.
Did you modify the zone data before pasting it in (i.e. mask
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Alex
> Sent: Thursday, 27 September 2018 2:52 AM
> To: bind-users@lists.isc.org
> Subject: BIND and UDP tuning
>
> Hi,
>
> I reported a few weeks ago that I was experiencing a really high
>
> -Original Message-
> From: Tony Finch [mailto:d...@dotat.at]
>
> > - { name: 'net.ipv4.tcp_sack', value: 0 }
>
> Why? SACK is super important for TCP performance over links that have any
> degree of lossiness, and I don't recall hearing of any caveats.
>
> Tony.
> --
>
Hi,
Whilst I've confirmed that notifies can be sent to alternate ports (using
masters definitions), I can't seem to mangle BIND to use an alternate port in a
view's match-destination configuration item (as it takes an ACL and they don't
take ports from what I can read/test).
Am I missing
Hi,
I noticed that over the last few days on a number of our name servers in Tokyo
that Google has started making persistent TCP connections to our name servers.
I'm all for this as a concept, but it appears they're making many thousands of
connections and not tearing them down after any given
Maybe to state a little clearer; the dnssec-keymgr is for the automation of
creation and date management of keys.
All of the actual signing does not require the new python bit. If you're happy
managing your keys with dnssec-keygen and dnssec-settime, you can continue
using those (non-python)
Whilst you mentioned 150 seats and you mentioned 'no firewalls', you didn't
mention the network topology at all, in particular is traffic passing through a
commercial firewall/router (hardware or virtualized) to get to the DNS server?
If there is, it may be worth checking what packet inspection
Congratulations on finding the cause.
Sometimes, it's the simplest of things.
Stuart
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Gregory
Sloop
Sent: Thursday, 6 June 2019 12:37 PM
To: bind-users@lists.isc.org
Subject: Re: Bind9 stops responding for some clients
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Evan Hunt
> Sent: Friday, 14 June 2019 5:40 AM
> To: Warren Kumari
> Cc: Ondřej Surý; comp-protocols-dns-b...@isc.org
> Subject: Re: A policy for removing named.conf options.
>
> On Thu,
Trying with +cd, +noedns and +tcp elicits a similar result; a SERVFAIL.
As these work fine if querying the authoritative servers directly (or using
+trace), it appears to be a quirk in the resolver code.
Stuart
> -Original Message-
> From: bind-users
Not sure if I responded to this last year, but thanks.
Stuart
> -Original Message-
> From: Tony Finch [mailto:d...@dotat.at]
> Sent: Wednesday, 19 December 2018 10:26 PM
> To: Browne, Stuart
> Cc: bind-users@lists.isc.org
> Subject: Re: BIND and persistent connections
&
It looks to me as if you are trying to generate a TSIG key for DNS updates. Try
using "tsig-keygen" instead.
Stuart
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> @lbutlr
> Sent: Monday, 2 March 2020 1:13 PM
> To: bind-users
> Subject:
Sadly, no ideas other than a shared experience. It's not just the Windows
release nor is it just the 9.14 series of releases; we've been witnessing this
since the 9.10 releases on Linux (whilst using inline-signing). I don't recall
off the top of my head if we saw it in the 9.9 series; even for
On 6/5/20, 02:21, "bind-users on behalf of Chuck Aurora"
wrote:
On 2020-05-02 14:35, Reindl Harald wrote:
> Am 02.05.20 um 21:31 schrieb Chuck Aurora:
>> On 2020-05-02 13:23, Erich Eckner wrote:
>>> Will there be client-side DoT/DoH support in bind, too? E.g. will my
>>>
You might want to look at the requestor machine's "search" domains.
If the stub resolver starts appending search domains when it doesn't get a
response it can use.
Stuart
On 8/9/20, 09:51, "bind-users on behalf of L. A. Walsh"
wrote:
Notice: This email is from an external sender.
Just one quick one before I run off to lunch with regards to section 2:
- Try to avoid crossing NUMA boundaries. At high throughput, the context
switching and far memory calls kills performance.
Stuart
From: bind-users on behalf of Victoria Risk
Date: Wednesday, 8 July 2020 at 11:58
To:
38 matches
Mail list logo
