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 cryptographic difference between the
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
gt;
> Browne, Stuart via bind-users wrote:
> >
> > I was wondering if anybody had any thoughts on how to limit the
> > concurrency or at least the lifetime of these persistent connections
> > within BIND.
>
> If you are running BIND 9.12, you have a bunch of new
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:
29 matches
Mail list logo
