On 04/03/2024 14:06, Jiaming Zhang wrote:
Then I should download the source, there's no devel package for this one in the
repo.
That's not necessary. Oracle Linux keeps many of the -devel packages in
its "codeready_builder" repository, which is not enabled by default. As
root, you need to
On 04. 03. 24 14:06, Jiaming Zhang wrote:
Then I should download the source, there's no devel package for this one
in the repo.
First question is if you need to compile yourself. Most people don't and
can use precompiled packages. Have a look here:
with the Dutch Chamber of Commerce trade register with number
85744115.
Van: Anand Buddhdev
Verzonden: Monday, March 4, 2024 2:04:35 PM
Aan: Jiaming Zhang ; bind-users@lists.isc.org
Onderwerp: Re: Update to 9.18 failed due to libuv
On 04/03/2024 13:56, Jiaming Zhang
On 04/03/2024 13:56, Jiaming Zhang wrote:
Hi Jiaming,
Recently I was trying to upgrade bind from 9.16 to 9.18. However, running
`./configure` return an error stating the `libuv` was not found. I have this
library installed (version 1.41.1) via dnf, and can can find it using `rpm -ql`
which
Dear community,
Recently I was trying to upgrade bind from 9.16 to 9.18. However, running
`./configure` return an error stating the `libuv` was not found. I have this
library installed (version 1.41.1) via dnf, and can can find it using `rpm -ql`
which shows the library is under `/usr/lib64`.
Hi Mounika
If you connect to a secondary nameserver to accept dynamic zone updates you
have to configure on the secondary inside the slave zone section a statement:
allow-update-forwarding { dhcp-updates; };
...where "dhcp-updates" is an ACL (that could be na
On 14.02.24 17:06, trgapp16 via bind-users wrote:
I configured Bind 9.18.12 as slave DDNS with dynamic updates from DHCP (ISC
DHCP 4.4)
running on the same server (Ubuntu 22.04 server)
When I run "named-checkconf named.conf", I get the following error
"named.conf:2018: optio
Hello,
I configured Bind 9.18.12 as slave DDNS with dynamic updates from DHCP (ISC
DHCP 4.4)
running on the same server (Ubuntu 22.04 server)
When I run "named-checkconf named.conf", I get the following error
"named.conf:2018: option 'allow-update' is not allowed
Hi,
Disabling inline-signing is a good workaround. The issue is that BIND
with inline-signing maintains a signed file separately and needs to bump
the SOA SERIAL.
The serial queried is for the DNSSEC signed zone, but the dynamic update
is done against the unsigned version of the zone. Hence
Am 08.07.2023 um 08:48 schrieb Matthias Fechner:
If I try now to update some records remotely on the server I see in
the log of the server:
==> /var/named/var/log/named.log <==
08-Jul-2023 07:40:22.962 update-security: info: client @0x848ac0760
93.182.104.69#18475/key idefix.fechn
Hi,
Have a look at nsupdate
(https://bind9.readthedocs.io/en/v9.18.19/manpages.html#nsupdate-dynamic-dns-update-utility)
as well. This can be used to update the zone without direct editing
and thus no need for freezing and thawing.
Thank you,
Darren Ankney
On Fri, Sep 22, 2023 at 3:43 PM Jan
. There is no way to
inhibit this. Note also, that the zone file must not be edited by hand without
prior `rndc freeze' and subsequent `rndc thaw', and note that freezing a zone
forbids updates.
As a side note I'd like to recommend using the much more granular `update
policy' on the zone.
-JP
Hello!
I´m using Bind 9.11 .
I´m automating my dns server with ansible (nsupdate module). To do this I
enabled the configuration directive allow-update. After the first automated
name change, my zone file was unformatted. I lost the comments and more
than 500 occurrences of the ORIGIN parameter
Am 05.07.2023 um 13:13 schrieb Matthias Fechner:
So far, nsdiff generates expected output, next step is now to apply
the changes in an automated way.
If I try now to update some records remotely on the server I see in the
log of the server:
==> /var/named/var/log/named.log <==
08-Ju
Hi Nick,
Am 04.07.2023 um 08:17 schrieb Nick Tait via bind-users:
It looks like nobody solved your /original/ problem? If you are still
looking for an answer it might help if you posted some logs? The
people on this list are good at interpreting any errors you're seeing. :-)
thanks a lot for
Am 04.07.2023 um 10:16 schrieb Matthew Seaman:
By default, the primary server will end up with a `fetchner.net` zone
data file in text format which contains the pretty much the same RRs
as your master copy in git, but reformatted into a standard style,
sorted into order and with comments
On 03/07/2023 19:36, Matthias Fechner wrote:
What I understood from the documentation:
*-s* /server/[#/port/]
I can maintain e.g. my zones from my local computer at home inside a git
repository and use nsdiff and nspatch to push the changes to the server
in the internet?
Correct.
Does the
/23 11:29 PM (GMT+12:00) To: bind-users@lists.isc.org Subject: How
to update zone with dnssec-policy Dear all,I have the following problem that
changes in a zone file do not get active, no matter if I reload the zone using
rndc or restarting bind 9.16.42 on FreeBSD.If I update a zone I edit
set up zone
policies and distribute keys appropriately. Although if you run nsdiff
directly on your primary DNS machine, you should be able to use the
built-in /var/run/named/session.key with a per-zone policy like:
```
update-policy {
grant local-ddns zonesub any
On 02/07/2023 12:27, Matthias Fechner wrote:
I have the following problem that changes in a zone file do not get
active, no matter if I reload the zone using rndc or restarting bind
9.16.42 on FreeBSD.
If I update a zone I edit the zone file, adapt the serial in the SOA and
normally do a rndc
Dear all,
I have the following problem that changes in a zone file do not get
active, no matter if I reload the zone using rndc or restarting bind
9.16.42 on FreeBSD.
If I update a zone I edit the zone file, adapt the serial in the SOA and
normally do a rndc reload fechner.net
> On 24 May 2023, at 13:59, Patrick Rynhart wrote:
>
> Currently we have (for our Master zone) a list of IPs that can update
> our DNS master using the allow-update statement:
>
> zone "redacted.ac.nz" {
> type master;
> allow-update {
>
Currently we have (for our Master zone) a list of IPs that can update
our DNS master using the allow-update statement:
zone "redacted.ac.nz" {
type master;
allow-update {
::1;
127.0.0.1;
131.123.103.2;
131.123.88.3;
...
}
We are wanting to transition to the m
do not feel
obligated to reply outside your normal working hours.
> On 14. 3. 2023, at 19:00, Vladimir Brik
> wrote:
>
> Thanks, quoting worked!
>
> Does anybody know if the socket of an "external" update-policy supposed to
> receive data for every dynamic DNS up
Hi Vlad,
Did you specify the socket filename (/tmp/sock from your update-policy
example) when running it? According to the man page:
https://bind9.readthedocs.io/en/v9_18_11/manpages.html#nsupdate-dynamic-dns-update-utility
the final argument for the command line is an optional filename
Thanks, quoting worked!
Does anybody know if the socket of an "external"
update-policy supposed to receive data for every dynamic DNS
update?
I `strace`ed the `named` process and pushed some updates
using nsupdate, but I saw no attempts to do anything with
the socket file
I haven't used this personally, but in the system tests, this works:
update-policy {
grant administra...@example.nil wildcard * A SRV CNAME;
grant testden...@example.nil wildcard * TXT;
grant "local:/tmp/auth.sock" extern
Hello
I am trying to set up an "external" dynamic DNS update
policy but I can't figure out the syntax.
The documentation [1] says that the "identity" field needs
to be in the form local:PATH, but using something like the
following results in an error: "expec
Thanks Mark - that was the issue :-)
I really, really appreciate the help
Cheers
Dulux-Oz
On 04/02/2023 23:21, Mark Andrews wrote:
Add DHCID to the list of record types permitted to be updated by the DHCP
server.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
;dnssec_log";
> "default_debug";
> };
> category "default" {
> "default_syslog";
> "default_debug";
> "default_log";
> };
> category "delegation-only" {
> "
default_log";
};
category "delegation-only" {
"auth_servers_log";
"default_debug";
};
category "edns-disabled" {
"auth_servers_log";
"default_debug";
};
category "lame-servers&qu
You need to replace the rule type with something more appropriate for the type
of update being preformed. For the updates made by the DHCP server I would use
“zonesub”. “name” is fine for LetsEncrypt.
update-policy {grant update-key zonesub A ;};
update-policy {grant
e able to help you.
>
> That being said, your update policy statements don't look correct to
> me. Have you tried to load them with BIND? Do they pass syntax check?
> The reason they don't look right is that they seem to follow this
> format correctly:
>
> # (grant | deny ) identity r
You would probably need to attach your entire named.conf file (with
sensitive bits (keys and the like) redacted
named-checkconf -px
is your friend: prints out the named.conf and included files in canonical form
if no errors were detected and obscures shared secrets by replacing them with
You would probably need to attach your entire named.conf file (with
sensitive bits (keys and the like) redacted and perhaps subnets
obscured to examples such as 192.0.2.0/24, for example) before anyone
would be able to help you.
That being said, your update policy statements don't look correct
Hi All,
I'm pretty new to configuring Bind and so it would be great if
someone(s) could just check my code re: the update-policy zone
command(s) below - thanks in advance.
For the first zone (a regular internal forward-lookup zone) I'd like to
be able to update (from Kea via ddns) the zone
Saw this at startup:
18:09:14.595420 IP (tos 0x0, ttl 57, id 35985, offset 0, flags [none], proto
UDP (17), length 1167)
192.58.128.30.53 > 24.116.100.90.53955: [udp sum ok] 64207*- q: DNSKEY? .
4/0/1 . DNSKEY, . DNSKEY, . DNSKEY, . RRSIG ar: . OPT UDPsize=1472 DO (1139)
18:09:14.597537 IP
> On May 14, 2022, at 12:35 AM, Matus UHLAR - fantomas
> wrote:
>
> On 13.05.22 10:06, Philip Prindeville wrote:
>> After rebooting my OpenWRT router with Bind 9.18.1 yesterday, I started
>> seeing a lot of:
>>
>>
>> May 12 19:24:06 OpenWrt named[11061]: validating ./NS: no valid
On 24-10-2022 15:14, PGNet Dev wrote:
The good news it is not stuck.
What indicator flags that it IS 'stuck'? Is it explicitly logged?
Because the keymgr logs says it is just waiting time?
2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022
16:55:22.689 dnssec: debug 1: keymgr:
The good news it is not stuck.
What indicator flags that it IS 'stuck'? Is it explicitly logged?
BIND is waiting to make sure the new DS is also known to the validators. The
time being evaluated here is the DS TTL, plus parent-propagation-delay, plus
retire-safety. All these three values
Hi,
On 21-10-2022 23:05, PGNet Dev wrote:
I exec
rndc dnssec -checkds -key 63917 published example.com IN external
with dnssec loglevel -> debug, on exec, in logs
2022-10-21T16:55:22.690603-04:00 ns named[36683]: 21-Oct-2022
16:55:22.689 dnssec: debug 1: keymgr: examine KSK
I exec
rndc dnssec -checkds -key 63917 published example.com IN external
with dnssec loglevel -> debug, on exec, in logs
2022-10-21T16:55:22.690603-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689
dnssec: debug 1: keymgr: examine KSK example.com/ECDSAP256SHA256/63917 type DS
in state
om.+013+63917.state
!! DSState: rumoured
ds state is still just "rumoured".
What additional steps are needed to update that DSState correctly?
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this sof
Hello all,
I have a problem that my DHCPv6 DDNS update which works reliably with
IPv4 doesn't work at all when we implemented
the dual-stack operation. There is not even a warning, notice or error
in the log. No syntax errors in the config /etc/dhcp/dhcpd6.conf file.
We are running Debian 10
Hello all,
I have a problem that my DHCPv6 DDNS update which works reliably with
IPv4 doesn't work at all when we implemented
the dual-stack operation. There is not even a warning, notice or error
in the log. No syntax errors in the config /etc/dhcp/dhcpd6.conf file.
We are running Debian 10
Using nsupdate when I try to delete an MX record for a domain, I get REFSUED.
REFUSED is also reported when attempting to update a non-dynamic zone. Are you
sure the zone you're trying to update is actually dynamic?
How do I remove and replace the MX record for a domain with nsupdate?
del
@lbutlr wrote:
> Using nsupdate when I try to delete an MX record for a domain, I get
> REFSUED.
>
> When I try to add an MX record with the same priority (or not), it
> leaves the old record as well.
>
> How do I remove and replace the MX record for a domain with nsupdate?
Show your procedure.
--
Mark Andrews
> On 5 Jun 2022, at 06:37, @lbutlr wrote:
>
> Using nsupdate when I try to delete an MX record for a domain, I get REFSUED.
>
> When I try to add an MX record with the same priority (or not), it leaves the
> old record as well.
>
> How do I remove and
Using nsupdate when I try to delete an MX record for a domain, I get REFSUED.
When I try to add an MX record with the same priority (or not), it leaves the
old record as well.
How do I remove and replace the MX record for a domain with nsupdate?
--
A woman stays up all night with two men
On 13.05.22 10:06, Philip Prindeville wrote:
After rebooting my OpenWRT router with Bind 9.18.1 yesterday, I started seeing
a lot of:
May 12 19:24:06 OpenWrt named[11061]: validating ./NS: no valid signature found
May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid signature
Your MTU is not the point. It's what happens beyond your equipment that may
have a bearing. However, as I said, I don't think IP fragmentation will be
your problem in this case, so that's a whole other discussion for a
different day.
pcaps are your friend though. From a packet capture you can see
My MTU is 1500 bytes, so I don't think that's the problem.
But UDP can fragment via IP...
> On May 13, 2022, at 10:34 AM, Greg Choules
> wrote:
>
> Hi Philip.
> Can you run packet captures? I'm running 9.18.0 (close enough?) in Docker and
> just traced what happens going from
Hi Philip.
Can you run packet captures? I'm running 9.18.0 (close enough?) in Docker
and just traced what happens going from "dnssec-validation no;" to
"dnssec-validation auto;" It makes a DNSKEY query for "." to one of the
roots. The response size was over 900 bytes, so depending on what UDP
After rebooting my OpenWRT router with Bind 9.18.1 yesterday, I started seeing
a lot of:
May 12 19:24:06 OpenWrt named[11061]: validating ./NS: no valid signature found
May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid signature
found
May 12 19:24:06 OpenWrt named[11061]: no
On 2022 Apr 12, at 18:25, @lbutlr wrote:
>
> My secondary DNS server (bind916-9-16-27) is reporting:
>
> managed-keys-zone: Failed to create fetch for DNSKEY update
Named.conf relevant settings (I think) are:
recursion yes;
allow-query { any; };
all
My secondary DNS server (bind916-9-16-27) is reporting:
managed-keys-zone: Failed to create fetch for DNSKEY update
At this point it only respond SERVFAIL to all queries.
The secondary DNS is a spare machine that is not used for anything else but
DNS, so no one has touched it other than
: bind-users@lists.isc.org
Subject: [EXTERNAL] Re: NOTAUTH on dynamic update followed by approved update
Hellige, Charles D wrote:
> We have been using nsupdate for some time without issue. We recently
> started seeing NOTAUTH failures in the named logs followed by
> successful adding
AUTH) errors before we finally get a
> successful message.
My wild guess is that someone is using a DNS UPDATE client that has a
noisy and blundering algorithm for working out which zone it is updating.
In a DNS UPDATE message, the first section (corresponding to the question
section in a n
message.
config : zone "ops.company.com" { type master; file
"/usr/local/etc/namedb/grn/fwd/ops.company.com.db"; allow-update { key
"grn-mid"; }; };
11-Mar-2022 10:07:19.748 update: info: grn-mid: view GRN: updating zone
'ops.company.com/IN': update failed: not
Looks like you're trying to use the setup in that serverfault link.
That example only works on an internal network. I thought the
186.198.193. part was enough to make the zone unique. But your
assertion is correct: I would collide if any other administrators on
other subnets in range 193.198.186.0/
the name resolution is more stable with the
secondary (slave) servers for the zone.
Kind regards,
Mirsad Todorovac
On 13.12.2021. 9:25, Mirsad Goran Todorovac wrote:
Hello Crist,
The good news is that it seems that the dynamic DDNS update from DHCP
works!
See here a snap from /var/log/syslog:
Dec
Hello Crist,
The good news is that it seems that the dynamic DDNS update from DHCP
works!
See here a snap from /var/log/syslog:
Dec 13 07:36:20 domac dhcpd[26031]: DHCPDISCOVER from 1c:66:6d:90:0b:f7
(ALU-ZAG-14) via 193.198.186.193
Dec 13 07:36:20 domac dhcpd[26031]: DHCPOFFER
t your
assertion is correct: I would collide if any other administrators on
other subnets in range 193.198.186.0/24 decide to make reverse DHCP
DDNS update in the future. Thanks for the thought!
The point of the example I gave is that you are going to build your
own reverse zone inside of a zone you con
. part was enough to make the zone unique.
But your assertion is correct: I would collide if any other
administrators on other subnets in range 193.198.186.0/24 decide to
make reverse DHCP DDNS update in the future. Thanks for the thought!
The point of the example I gave is that you are going
.
That example only works on an internal network.
I thought the 186.198.193. part was enough to make the zone unique.
But your assertion is correct: I would collide if any other
administrators on other subnets in range 193.198.186.0/24 decide to
make reverse DHCP DDNS update in the future. Thanks
DHCP
DDNS update in the future. Thanks for the thought!
The point of the example I gave is that you are going to build your
own reverse zone inside of a zone you control on the Internet. Now
that you've given some examples, I can perhaps make it more obvious
what I'm suggesting. Your DNS zone would
s. But right now I can't study all those and I just want to survive,
> providing a solution fast enough for our uplevel sysadmins.
>
> The /etc/bind/named.conf.local part looks like:
>
> zone "192/27.186.198.193.in-addr.arpa" in {
> type master;
> file
8.193.in-addr.arpa" in {
type master;
file "/etc/bind/zones/192-27.186.198.193.in-addr.arpa.db";
};
zone "186.198.193.dhcp" in {
type master;
file "/var/cache/bind/186.198.193.dhcp.db";
allow-update { key DDNS_UPDATE; };
};
186.198.193.rev.example.com
<http://193.186.198.193.rev.example.com>.
194 IN CNAME 194.186.198.193.rev.example.com
<http://194.186.198.193.rev.example.com>.
…
On Fri, Dec 10, 2021 at 2:51 PM Mirsad Goran Todorovac
wrote:
Hello,
I have a problem with DHCP DDNS update to BIND 9 re
, Dec 10, 2021 at 2:51 PM Mirsad Goran Todorovac <
mirsad.todoro...@alu.unizg.hr> wrote:
> Hello,
>
> I have a problem with DHCP DDNS update to BIND 9 reverse PTR zone subnet
> that is owned by several organizations, so I can't get a direct DHCP DDNS
> update access with a
Hello,
I have a problem with DHCP DDNS update to BIND 9 reverse PTR zone subnet
that is owned by several organizations, so I can't get a direct DHCP
DDNS update access with a key or with hostname.
I have been delegated domain name |192-27.186.198.193.in-addr.arpa from
the upper level admins
c: warning:
managed-keys-zone: Failed to create fetch for DNSKEY update
Nov 21 18:04:40 pole named[3722]: zoneload: info: zone ./IN:
loaded serial 2021112100 (DNSSEC signed)
Nov 21 18:04:40 pole named[3722]: zoneload: info: zone
10.in-addr.arpa/IN: loaded serial 2021080800
Nov 21 18:04:40 pole
As far as I am aware - and what I have always done - the normal thing to do is
to use a hints file. Lately the hints are built-in, so nothing is really needed.
One question that comes to mind:
What happens if the slaved root zones are not up to date /not correct? might
that be the cause?
--
Hija,
I finally found the cause of the error! As soon as I stop slaving
the root-zones and instead use the (configured or compiled-in)
hint-file, the error stops.
The actual error-condition (zone is not loaded) then becomes
obvious, because this RFC-5011 action happens very early, before
any
On Mon, Nov 15, 2021 at 09:14:19AM +0100, Ondřej Surý wrote:
! > On 15. 11. 2021, at 3:41, Peter wrote:
! >
! > Wondering
!
> On 15. 11. 2021, at 3:41, Peter wrote:
>
> Wondering
> * WHAT is broken?
> * Why does it happen only to me?
We can’t really help you if you don’t share any details of your installation
and configuration (hint: You can use `named-checkconf -px` to scrub the
configuration).
So far, you shared
Hi all,
I continuousely happen to see this message:
> local0.warn named[2291]:
> dnssec: warning: managed-keys-zone: Failed to create fetch for DNSKEY update
I see it on different nameservers, at different sites, with and
without views, with and without IPv6, and I see it every time when
On 11/10/2021 6:25 AM, Giddings, Bret wrote:
Is there any other facility for including effectively the same grant
statements within multiple zones?
I am not aware of any
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alaska.gov
Hello,
I want to use the same update-policy grant statements multiple times in
different zones and would therefore prefer to use something like an ACL.
It doesn’t appear to be the case that you can create something like
acl “FOO” {
grant EXAMPLE.COM krb5-self . A ;
grant * tcp-self . PTR(1
is not required; you already had "update-policy local;"
which gives you a key to use with nsupdate(8)'s -l option. This is
a perfectly valid way to maintain zone data, and in my opinion much
better than editing zone files and inline-signing. You have taken a
step backwards.
This has th
Wow. Thanks so much for all the responses. Really appreciate it. They made me
truly realize that a lot on the info on the net may be either incomplete or
just old. I understand a bit better now.
I added the line inline-signing yes; as was suggested and reloaded bind. I am
now seeing the
Peter Fraser wrote:
>
> I am using bind-9.14.x and here are the DNSSEC related entries in the zone.
>
> auto-dnssec maintain;
> update-policy local;
> key-directory “zones/domain-keys”;
How you go about this depends on whether your configuration enables
`inline-signing` or not.
bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Peter
Fraser
Sent: Sunday, May 09, 2021 8:49 PM
To: bind-users@lists.isc.org
Subject: Update DNSSEC Zone
HI All,
I really would appreciate a pointer in the right direction. I took over a bind
server recently. I am not new to bind. I
to update the DNSSEC zone. Can
anyone assist me please? I did see one site that said I could just put in
regular A record entries and run rndc reload and that would resign the zone. I
tried that but it didn’t work.
I am using bind-9.14.x and here are the DNSSEC related entries in the zone.
auto
the KAM ruleset: https://mcgrail.com/template/projects#KAM1
Regards,
KAM
On 4/27/2021 9:47 AM, Turritopsis Dohrnii Teo En Ming wrote:
Subject: [UPDATE 1] How to Easily Set Up a Full-Featured Linux Mail
Server on Ubuntu 18.04.5 LTS with iRedMail 1.4.0
Good day from Singapore,
I followed
Subject: [UPDATE 1] How to Easily Set Up a Full-Featured Linux Mail
Server on Ubuntu 18.04.5 LTS with iRedMail 1.4.0
Good day from Singapore,
I followed linuxbabe.com's Xiao Guoan's guide and successfully setup a
full featured Linux mail server on Ubuntu 18.04.5 LTS with IRedMail
1.4.0.
Author
location may be an contributing factor.
I coulda sworn I’d fixed that before...
I would not be surprised if a system update accidentally overwrote a
tweak to a SELinux policy.
If you can't tell, I prefer to leave things enabled at the security
posture they are at and provide exceptions
Turne out to be a dumdum mistake on my part. SELinux was set to enforce…set it
to permissive and voila! the .jnl file was created.
I coulda sworn I’d fixed that before...
> On Mar 5, 2021, at 12:39 PM, Grant Taylor via bind-users
> wrote:
>
> On 3/5/21 12:07 PM, Bruce Johnson wrote:
>>
named process is running as ’named’:
named 45631 1.0 11.8 411576 220744 ? Ssl 11:28 0:57
/usr/sbin/named -u named -c /etc/named.conf -t /var/named/chroot
if I run su --shell=/bin/sh named
I can create files in the directory the journal file should be.
On Mar 5, 2021, at
On 3/5/21 12:07 PM, Bruce Johnson wrote:
Fixing the permissions and restarting named got dynamic updating
working again, but new systems (ie names that are NOT already in
the Zone file ) are throwing errors about the journal file: error:
journal open failed: unexpected error
It seems like
I”m running it as named-chroot, and named is rw permissions at the /var/named
This is the directory listing:
[root@mydns named]# ls -l
total 16
drwxr-x---. 7 named named 61 Oct 9 13:30 chroot
drwxrwx---. 2 named named 127 Feb 28 03:27 data
drwxrwx---. 2 named named 60 Mar 4 13:57 dynamic
Fixing the permissions and restarting named got dynamic updating working again,
but new systems (ie names that are NOT already in the Zone file ) are throwing
errors about the journal file: error: journal open failed: unexpected error
Mar 5 11:44:34 mydns named[45631]: client @0x7fa31f4178d0
Thanks Mark.
On Tue, Jan 19, 2021 at 6:15 PM Mark Andrews wrote:
> Forwarding is designed for TSIG and works for SIG(0). It doesn’t work for
> GSS-TSIG.
>
> --
> Mark Andrews
>
> On 19 Jan 2021, at 22:23, Nagesh Thati wrote:
>
>
> Hi,
> I am getting upda
Forwarding is designed for TSIG and works for SIG(0). It doesn’t work for
GSS-TSIG.
--
Mark Andrews
> On 19 Jan 2021, at 22:23, Nagesh Thati wrote:
>
>
> Hi,
> I am getting update failed on master DNS appliance when I am using
> allow-update-forwadin
Hi,
I am getting update failed on master DNS appliance when I am using
allow-update-forwading,
*updating zone '_msdcs.example.com/IN <http://msdcs.example.com/IN>':
update failed: rejected by secure update (REFUSED)*
example.com is a active directory enabled zone which has one master a
Stop using IP addresses for UPDATE authentication. Use TSIG instead between the
DHCP server and named.
--
Mark Andrews
> On 19 Dec 2020, at 18:25, Dan Egli wrote:
>
> I guess sometimes you just need to look at it in a differnet way. I never
> noticed it was using the 10.0.2.
I guess sometimes you just need to look at it in a differnet way. I
never noticed it was using the 10.0.2.15 IP to try to update. That's
going to be blocked because I don't have the outside world enabled for
this server. So let me go ask on the DHCP list why it's insisting on
using
I'm really stumped as to what's going on. I'm trying to get dhcpd to
automatically update name records for my internal network. This is NOT
going to the public internet by any means. It's just an internal
network. But every time either I or dhcpd try to add a record, named
refuses to allow
On 14.07.2020 18:11, Zhiyong Cheng wrote:
在 2020年7月14日 +0800 PM9:06，Per Weisteen ，写道：
Hi
I've a BIND setup with my ISP with two views, one external and one
internal. At the same time I also need to be able to do a dynamic
update from some addresses within the internal range. This worked ok
在 2020年7月14日 +0800 PM9:06，Per Weisteen ，写道：
> Hi
>
> I've a BIND setup with my ISP with two views, one external and one internal.
> At the same time I also need to be able to do a dynamic update from some
> addresses within the internal range. This worked ok before I had to d
1 - 100 of 512 matches
Mail list logo
