ws installing it via "yum install yum-plugin-copr", though
> RHEL 7 seems to not have heard of a "yum-plugin-copr" package, so you
> have to prod it a bit (similarly for EPEL, which you are going to need
> for libnghttp2 if you plan to use the stable "bind"
(similarly for EPEL, which you are going to need
for libnghttp2 if you plan to use the stable "bind" repository, which
currently contains BIND 9.18):
# yum install
http://mirror.centos.org/centos/7/os/x86_64/Packages/yum-plugin-copr-1.1.31-54.el7_8.noarch.rpm
# yum install
https://dl.f
Modified the repo file to mimic the repo data provided from the isc web site
verbatim:
[copr:copr.fedorainfracloud.org:isc:bind]
name=Copr repo for bind owned by isc
baseurl=https://download.copr.fedorainfracloud.org/results/isc/bind/epel-7-$basearch/
type=rpm-md
skip_if_unavailable=True
]
name=Corp repo for bind owned by isc
baseurl=https://download.copr.fedorainfracloud.org/results/isc/bind/epel-7-x86_64/
skip_if_unavailable=True
gpgcheck=0
enabled=1
enabled_metadata=1
type=rpm-md
---same result.
V/R
Jim DeCaro
DISA
Systems Administrator
Windows and Unix/Linux Server Operations
On 28/04/2022 19:38, DeCaro, James John (Jim) CIV DISA FE (USA) via
bind-users wrote:
# yum-config-manager --add-repo
https://download.copr.fedorainfracloud.org/results/isc/bind/epel-7-$basearch/
Sigh. What do they teach at system administration school these days?
You see the variable
# yum-config-manager --add-repo
https://download.copr.fedorainfracloud.org/results/isc/bind/epel-7-$basearch/
--Results in the file:
/etc/yum.repos.d/download.copr.fedorainfracloud.org_results_isc_bind_epel-7-_.repo
Content of the repo file
On 28/04/2022 16:52, DeCaro, James John (Jim) CIV DISA FE (USA) via
bind-users wrote:
Dnf is not available. Therefore using yum
Linux Red Hat 7.9 virtual machine on VMware, has internet connectivity
Set up local repository in
/etc/yum.repos.d
james.j.decaro3@mail.mil
james.j.decaro3@mail.smil.mil
-Original Message-
From: Anand Buddhdev
Sent: Thursday, April 28, 2022 11:06 AM
To: DeCaro, James John (Jim) CIV DISA FE (USA) ;
bind-users@lists.isc.org
Cc: Mcallister, Reginald CTR DISA FE (USA)
Subject: [URL Verdict: Neutral
On 28/04/2022 16:52, DeCaro, James John (Jim) CIV DISA FE (USA) via
bind-users wrote:
Dnf is not available. Therefore using yum
Linux Red Hat 7.9 virtual machine on VMware, has internet connectivity
Set up local repository in
/etc/yum.repos.d
Dnf is not available. Therefore using yum
Linux Red Hat 7.9 virtual machine on VMware, has internet connectivity
Set up local repository in
/etc/yum.repos.d/download.copr.fedorainfracloud.org_results_isc_bind_epel-8-_.repo:
[copr:copr.fedorainfracloud.org:isc:bind]
name=Copr repo for bind
On 26-04-2022 14:25, Bjørn Mork wrote:
Matthijs Mekking writes:
What can you do to get it to "omnipresent"? Tell BIND that the DS is
in the parent (only do so if it is true of course). You can run
rndc dnssec -checkds published your.zone
And it should update the keyfile.
Matthijs Mekking writes:
> What can you do to get it to "omnipresent"? Tell BIND that the DS is
> in the parent (only do so if it is true of course). You can run
>
> rndc dnssec -checkds published your.zone
>
> And it should update the keyfile. You should t
Bjørn,
Perhaps you hit another quirk in the migration. I'll try to explain what
is happening, or what is supposed to happen.
When migrating to dnssec-policy, there are no state files. BIND tries to
deduce the state from the timing metadata and the durations from
dnssec-policy.
For the DS
Matthijs Mekking writes:
> To be precise, BIND updates the key files each keymgr run. But If the
> keymgr waits for an event (rather than a duration), it will retry
> every refresh key interval, which defaults to an hour.
>
> You can check the logs for "next key event&quo
Hi,
To be precise, BIND updates the key files each keymgr run. But If the
keymgr waits for an event (rather than a duration), it will retry every
refresh key interval, which defaults to an hour.
You can check the logs for "next key event" to see when the keymgr is
scheduled next.
ult.
>
> The setup is mostly working as expected - which is great. But there is
> one issue which has suprised me, and which is slightly annoying since it
> tends to set off a few security warnings: All the key related files are
> now touched by BIND once an hour, whether they are mo
and which is slightly annoying since it
tends to set off a few security warnings: All the key related files are
now touched by BIND once an hour, whether they are modified or not.
Which they obviously nevery should be, given my current policy.
This is particularily surprising wrt the deleted keys
ndy Bush wrote:
>
> sudo systemctl disable systemd-resolved.service
>sudo service systemd-resolved stop
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
> this list
>
> ISC funds the development of this software with paid suppor
sudo systemctl disable systemd-resolved.service
sudo service systemd-resolved stop
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org
provides you any benefit.
systemd-resolved strips in default configuration even DNSSEC signatures.
I would doubt it can handle key signatures or even updates.
On 4/18/22 07:26, Leroy Tennison via bind-users wrote:
> When I attempt “dig -t AXFR office.example.com -k
> Kexample_dns.+157+184
uot; [Microsoft]
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.
en forwarded from lists.isc.org.
I'm pretty sure the invalid DKIM signature counts as negative for gmail
even if the ISC DKIM signature is valid. And fixing that should be
within your control?
Bjørn
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this
org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Good points, thanks.
-Original Message-
From: Reindl Harald
To: bind-users@lists.isc.org
Sent: Mon, Apr 18, 2022 12:41 am
Subject: Re: Bind and systemd-resolved
Am 18.04.22 um 07:26 schrieb Leroy Tennison via bind-users:
> When I attempt “dig -t AXFR office.example.com
Thanks, had looked at 'man dig' but had assumed (oops) that only the items
listed under the various OPTIONS headings were available in .digrc. Glad to
learn that @ can also be used (confirmed with testing).
-Original Message-
From: Ondřej Surý
To: Leroy Tennison
Cc: bind-users
There are a lot of extraneous details in here. This is not a BIND problem.
On Mon, 18 Apr 2022, Leroy Tennison via bind-users wrote:
When I attempt “dig -t AXFR office.example.com -k Kexample_dns.+157+18424.key”
on the DNS server (Bind 9.11) sudoed to root I get:
Why do you need to be root
> On 18. 4. 2022, at 7:27, Leroy Tennison via bind-users
> wrote:
>
>
> When I attempt “dig -t AXFR office.example.com -k
> Kexample_dns.+157+18424.key” on the DNS server (Bind 9.11) sudoed to root I
> get:
>
> ;; Couldn't verify signature: expected
Am 18.04.22 um 07:26 schrieb Leroy Tennison via bind-users:
When I attempt “dig -t AXFR office.example.com -k
Kexample_dns.+157+18424.key” on the DNS server (Bind 9.11) sudoed to
root I get:
;; Couldn't verify signature: expected a TSIG or SIG(0)
; Transfer failed.
This is an Ubuntu 18.04
When I attempt “dig -t AXFR office.example.com -k Kexample_dns.+157+18424.key”
on the DNS server (Bind 9.11) sudoed to root I get:
;; Couldn't verify signature: expected a TSIG or SIG(0); Transfer failed.
This is an Ubuntu 18.04 system and /etc/systemd/resolved.conf has DNS=127.0.0.1
since
> On Apr 5, 2022, at 12:37 PM, John Thurston wrote:
>
> We've reached April, 2022. I expect, in the next 30-days or so, we'll be
> seeing an announcement regarding the change of contents of bind-esv, bind,
> and bind-dev
>
> Is it reasonable to expect these change
On 1/26/2022 9:09 AM, Victoria Risk wrote:
For those using the ISC BIND packages:
Because we are still patching 9.11, and we haven’t yet issued a new
development branch, we are putting 9.18.0 into the bind-dev
repositories, for now.
In April, we plan to do a version rollover:
- bind-esv
> On 25. 3. 2022, at 16:16, Borja Marcos wrote:
>
> That said (and this is just an opinion) with all due respect of course, if
> bind evolves in a way that makes
> it much harder to build on non Linux systems, I am concerned.
That’s simply not true in general. We stopped su
> On 25. 3. 2022, at 17:43, Dennis Clarke via bind-users
> wrote:
>
> The entire ISC *preocess* has become gradually more toxic for at
> least a decade.
The only thing that’s toxic here is your current and previous communication
to the bind-users mailing list. Please, stop.
On 3/25/22 09:37, The Doctor via bind-users wrote:
On Fri, Mar 25, 2022 at 11:49:54AM +0100, Borja Marcos wrote:
Following up on this subject, looks like there were substantial changes to the
build process for 9.18.1? The port maintainers
seem to be having a hard time with it.
You got
> On 25. 3. 2022, at 16:16, Borja Marcos wrote:
>
> That said (and this is just an opinion) with all due respect of course, if
> bind evolves in a way that makes
> it much harder to build on non Linux systems, I am concerned.
That’s certainly not true for systems listed i
My apologies. I am not intending to be offensive of course!
I am just a spectator (I am using bind but I am not one of the maintainers nor
I have time for that).
That said (and this is just an opinion) with all due respect of course, if bind
evolves in a way that makes
it much harder to bui
essed up and so are some libraries
and man pages.
> Cheers,
>
>
>
>
>
> Borja.
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
> this list
>
> ISC funds the development of this software with paid support subscriptions.
ide your normal working hours.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-user
Following up on this subject, looks like there were substantial changes to the
build process for 9.18.1? The port maintainers
seem to be having a hard time with it.
Cheers,
Borja.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds
orts) it compiled and Sphinx didn’t complain.
And of course I ran configure after installing Sphinx.
Making all in man
gmake[3]: Entering directory '/usr/home/borjam/src/bind-9.18.1/doc/man'
echo ".. |rndc_conf| replace:: ``@sysconfdir@/rndc.conf``\n.. |rndc_key|
replace:: ``@
On 17. 03. 22 10:02, Borja Marcos wrote:
On 17 Mar 2022, at 08:59, Petr Špaček wrote:
Hello,
On 17. 03. 22 8:49, Borja Marcos wrote:
Trying to compile bind 9.18.1 on FreeBSD I am stumbling upon a really silly
problem. Getting plenty of errors like this
building the man pages.
building [man
> On 17 Mar 2022, at 08:59, Petr Špaček wrote:
>
> Hello,
>
> On 17. 03. 22 8:49, Borja Marcos wrote:
>> Trying to compile bind 9.18.1 on FreeBSD I am stumbling upon a really silly
>> problem. Getting plenty of errors like this
>> building the man pages.
&g
n pages, and other group of people don't that much :shrug:.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users
Hello,
On 17. 03. 22 8:49, Borja Marcos wrote:
Trying to compile bind 9.18.1 on FreeBSD I am stumbling upon a really silly
problem. Getting plenty of errors like this
building the man pages.
building [man]: all source files
updating environment: [new config] 34 added, 0 changed, 0 removed
Hi
Trying to compile bind 9.18.1 on FreeBSD I am stumbling upon a really silly
problem. Getting plenty of errors like this
building the man pages.
building [man]: all source files
updating environment: [new config] 34 added, 0 changed, 0 removed
reading sources... [100%] tsig-keygen
no errors. I do have bind restarting once a week via chron. It
restarted early this morning and of course it failed to come up with no errors
in the log, making it difficult to troubleshoot ☹
than do yourself a favor and include the named-checkzone in your cron
script before restart it hard
Reindi, thanks for the explanation, I do manually edit the zones because we
don’t make many DNS changes these days and I usually do named-checkzone but I
missed that this time, although I did reload that problematic zone with rndc
reload and saw no errors. I do have bind restarting once a week
Am 15.03.22 um 14:37 schrieb Paul Amaral via bind-users:
Neverminded, I was able to traceback my steps and realize a fat fingered
a DNS entry in one of the zones, added two periods to an authoritative
zone’s DNS record, causing bind to fail to start. The concerning issue
Neverminded, I was able to traceback my steps and realize a fat fingered a
DNS entry in one of the zones, added two periods to an authoritative zone’
s DNS record, causing bind to fail to start. The concerning issue was there
was no error on the logs at all, making it hard to figure out the issue
Am 15.03.22 um 14:08 schrieb Paul Amaral via bind-users:
Hi, I realize this is related to Centos, but all the sudden chroot bind
failed to start up with any meaningful errors.
you need to debug this terrible "ExecStartPre" where the package
maintainer was too lazy to include a s
Hi, I realize this is related to Centos, but all the sudden chroot bind
failed to start up with any meaningful errors.
Anyone know what might be the issue here? I have no clues on that the issue
is.
Paul
Job for named-chroot.service failed because the control process exited with
error code
Hello,
As part of our policy of pre-notification of upcoming security releases,
we are writing to inform you that the March 2022 BIND maintenance
releases that will be released on Wednesday, 16 March, will contain a
patches for a security vulnerabilities affecting the BIND 9.11.x, 9.16.x
ontains RRSIGs
> > which make it much harder to work with when editing manually - which I
> > need to do from time to time (while doing rndc freeze + rndc thaw)
> >
> > I noticed this is only happening when zone allows dynamic updates.
> > Zones that do not allow dynamic
time (while doing rndc freeze + rndc thaw)
>
> I noticed this is only happening when zone allows dynamic updates.
> Zones that do not allow dynamic updates are not touched.
>
> I have tried to create a fresh new zone, then sign it and the behavior
> is consistent.
>
> A
mic updates are not touched.
I have tried to create a fresh new zone, then sign it and the behavior
is consistent.
Am I doing something wrong? Is there config option, that will tell
bind to stop rewriting that zone file?
My version is 9.16.26.
Thanks
Josef
--
Visit https://lists.isc.org/mailm
make sense. But
the new computer, new (to me) OS version, and new architecture makes this the
perfect time to switch.
--
Larry Stone
lston...@stonejongleux.com
> On Feb 26, 2022, at 3:27 AM, @lbutlr wrote:
>
> On 2022 Feb 22, at 04:31, Julien Salort wrote:
>> For informati
On 2022 Feb 22, at 04:31, Julien Salort wrote:
> For information, bind 9.18.0 compiles fine under Macports on a variety of
> systems, including Catalina.
And with homebrew as well, though I don't know what versions of macOS it does
back to (Everything here is now on M1s with Mo
Le 22/02/2022 à 02:29, Larry Stone a écrit :
So, just for fun, I decided to see if I could build 9.18.0 on my current
MacBookPro (where I already run 9.16.26). It’s on MacOS Catalina 10.15.7
(cannot go higher - new MacBookPro coming soon!).
For information, bind 9.18.0 compiles fine under
Ondrej, thanks. Some quick searching tells me it’s a long-standing issue with
Xcode 10 (and before). Since Bind 9.16.26 works, not a pressing issue for me
and the system is likely to be replaced before 9.16 reaches EOL.
--
Larry Stone
lston...@stonejongleux.com
> On Feb 21, 2022, at 10
iMac) is also due for replacement
> so it may just have to live with Bind 9.16.x until it is replaced.
>
> But in case anyone has any ideas, the error make throws is:
>
> Making all in isc
> CC netmgr/libisc_la-netmgr.lo
> netmgr/netmgr.c:3536:10: error: address argumen
have to live with Bind 9.16.x until it is replaced.
But in case anyone has any ideas, the error make throws is:
Making all in isc
CC netmgr/libisc_la-netmgr.lo
netmgr/netmgr.c:3536:10: error: address argument to atomic operation must be a
pointer to non-const _Atomic type ('const
ttp2.org per the
> link in the release notes, built and installed it. Attempted to configure
> bind 9.18.0 and this time configure aborted with:
> configure: error: in `[redacted dirpath]/bind-9.18.0':
> configure: error: EVP_DigestSignInit/EVP_DigestVerifyInit support in OpenSSL
&g
. I downloaded nghttp2 (v1.46.0) from nghttp2.org per the
link in the release notes, built and installed it. Attempted to configure bind
9.18.0 and this time configure aborted with:
configure: error: in `[redacted dirpath]/bind-9.18.0':
configure: error: EVP_DigestSignInit/EVP_DigestVerifyInit
We're running it on a few different Debian servers with a mix of BIND as
well as Apache and nginx (among others). Aside from this following
problem and solution, we've had no issues:
https://support.sophos.com/support/s/article/KB-34610?language=en_US
-Jon
On 2022-02-18 3:32 p.m., Bruce
We getting a centralized IT push to install the university’s sophos product on
all servers, including linux:
https://docs.sophos.com/central/Customer/help/en-us/central/Customer/concepts/SPLCommandLineOptions.html
We have three systems running bind: a primary and two secondaries; all
ontain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for mor
* IN A 192.168.1.6
* IN A 192.168.1.7
-Original Message-
From: bind-users On Behalf Of
bind-users-requ...@lists.isc.org
Sent: Thursday, February 17, 2022 3:00 PM
To: bind-users@lists.isc.org
Subject: bind-users Digest, Vol 3907, Issue 3
Send bind-users mailing list
to hear what you see re: 9.16.25.
Mark.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
n anyast pool, but one
of them gets more email server requests while the
other one receives mostly customer queries.
Borja.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Co
On 16. 02. 22 10:12, Ondřej Surý wrote:
I guess you can possibly workaround this by disabling jemalloc from named build
and hope that the static shims for jemalloc calls will trump the preloaded
functions from libfaketime.
Oh right, I forgot we can also compile BIND without jemalloc
/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
faketime/issues/130.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@list
Hi,
it is even more complicated:
- Latest version of Deckard uses Linux network namespaces and thus makes
BIND GL#2088 unnecessary
- It does not work anyway because jemalloc library used by libfaketime
breaks libfaketime library is used by Deckard for DNSSEC tests. See
https://github.com
16. 2. 2022, at 8:32, Sun Guonian via bind-users
> wrote:
>
> Hi,
>
> I notice that Deckard project can be used to test
> knot/knot-resolver/unbound/pdns except BIND.
> And I try to write the configuration and template files for named, but it
> didn't work.
&g
)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 16. 2. 2022, at 8:32, Sun Guonian via bind-users
> wrote:
>
> Hi,
>
> I notice that Deckard project can be used to test
&g
Regards,SUN Guonian
P.S.Deckard's homepage on github.com is https://github.com/CZ-NIC/deckard
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact
ts between the machines inside and the machines outside to establish
> whether port number is the problem. e.g. use "dig -p"
>
> Thanks, Greg
>
>
> On Fri, 11 Feb 2022 at 16:30, Jakob Bohm via bind-users <
> bind-users@lists.isc.org> wrote:
>
>> On 20
ote:
>
> It's not BIND's fault or responsibility, but I hope it is well documented
> and remains well documented.
>
>> On Fri, 11 Feb 2022, Ondřej Surý wrote:
>> [...]
>> when out-of-order response processing was introduced in BIND 9.11.0, there
>> was
>> a
It's not BIND's fault or responsibility, but I hope it is well documented
and remains well documented.
On Fri, 11 Feb 2022, Ondřej Surý wrote:
[...]
when out-of-order response processing was introduced in BIND 9.11.0, there was
a “defensive” option added called keep-response-order that takes
On Fri, Feb 11, 2022 at 10:21 AM Tim Daneliuk via bind-users <
bind-users@lists.isc.org> wrote:
>
> After some months of poking around, we are now certain that our so-called
> "Business"
> service from Comcast is compromising our DNS servers because of their
> ex
.
Ted
On 2/11/2022 7:20 AM, Tim Daneliuk via bind-users wrote:
After some months of poking around, we are now certain that our
so-called "Business"
service from Comcast is compromising our DNS servers because of their
execrable "Security Edge" garbage. (They a
hours.
> On 11. 2. 2022, at 16:21, Tim Daneliuk via bind-users
> wrote:
>
>
> After some months of poking around, we are now certain that our so-called
> "Business"
> service from Comcast is compromising our DNS servers because of their
> execrable "Sec
On 2022-02-11 16:20, Tim Daneliuk via bind-users wrote:
After some months of poking around, we are now certain that our
so-called "Business"
service from Comcast is compromising our DNS servers because of their
execrable "Security Edge" garbage. (They are willing to r
ness?
TIA,
Tim
P.S. My guess is that this so-call "security" service is no such thing, or at
least its not the only thing. They are probably harvesting DNS lookups
to sell as marketing data, or at least that would be my first guess.
--
Visit https://lists.isc.org/mailman/list
Hi,
when out-of-order response processing was introduced in BIND 9.11.0, there was
a “defensive” option added called keep-response-order that takes ACL as option
to enable the previous behaviour where the DNS responses were sent in the same
order as the received DNS queries.
For BIND 9.19
On 2022-02-01 17:59, Danny Mayer via bind-users wrote:
Just run it as a docker image. Docker runs on Windows.
next will be we all run windows 12 in docker :)
/me hiddes, i am still using gentoo
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC
Check the list archives beginning April 2021 for the thread:
Deprecating BIND 9.18+ on Windows (or making it community improved and
supported)
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
available... is the plan to include
support to Windows at some point, to some current or future Windows
Server version, or is it a fact already, that no more Windows past
9.16.x?
there were discussions starting here
https://lists.isc.org/pipermail/bind-users/2021-April/104506.html
further
to Windows at some point, to some current or future Windows Server
version, or is it a fact already, that no more Windows past 9.16.x?
Jukka
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support
On 01. 02. 22 15:43, Anand Buddhdev wrote:
On 01/02/2022 15:33, Petr Špaček wrote:
Hi Petr,
As you correctly noticed, the log message "adjusted limit on open
files from 4096 to 1048576" already shows that BIND adjusted OS-level
file descriptor limit.
The only way out is what
On 01/02/2022 15:33, Petr Špaček wrote:
Hi Petr,
As you correctly noticed, the log message "adjusted limit on open files
from 4096 to 1048576" already shows that BIND adjusted OS-level file
descriptor limit.
The only way out is what Tony wrote in another thread: Add "-S "
On 01. 02. 22 13:30, Anand Buddhdev wrote:
Hi Ondrej,
Do you recommend setting LimitNOFILE=1048576 in the systemd unit file
for BIND?
I'm not Ondrej, but let me try:
No, that would be redundant.
As you correctly noticed, the log message "adjusted limit on open files
from 4096 to 10
Hi Ondrej,
Do you recommend setting LimitNOFILE=1048576 in the systemd unit file
for BIND?
Regards,
Anand
On 28/01/2022 15:03, Anand Buddhdev wrote:
Hi Ondrej,
It is 1024. I see named logging this:
adjusted limit on open files from 4096 to 1048576
I thought there was no need to set
Consortium
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://l
https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
limit before starting the server?
(ulimit -n)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org
and Buddhdev wrote:
>
> I just tried to start BIND 9.16.25 on a server with 88 vCPUs, running CentOS
> 7. Systemd is used to start BIND, and it emits the following:
>
> general: notice: starting BIND 9.16.25 (Extended Support Version)
> general: notice: running on Linux x86_64
I just tried to start BIND 9.16.25 on a server with 88 vCPUs, running
CentOS 7. Systemd is used to start BIND, and it emits the following:
general: notice: starting BIND 9.16.25 (Extended Support Version)
general: notice: running on Linux x86_64 3.10.0-1160.24.1.el7.x86_64 #1
SMP Thu Apr 8
t;> Ok, but does sig-validity-interval affect too, after the key deletion date?.
>> Or does it affect only from the inactivation date to the deletion date of a
>> key?.
sig-validity-interval and re-signing is independent of inactive and
delete dates.
> Mark
>
> Best reg
501 - 600 of 6382 matches
Mail list logo
