On 18/04/2023 2:16 am, Matt Zagrabelny via bind-users wrote:
On Mon, Apr 17, 2023 at 9:04 AM Marco wrote:
Am 17.04.2023 um 08:59:29 Uhr schrieb Matt Zagrabelny via bind-users:
> I'm running a little older Debian bind:
>
> bind9 1:9.9.5.dfsg-9
The upgrade your
On 18/04/2023 2:43 am, Greg Choules via bind-users wrote:
Why do you need it? Do you have some secondaries that are not listed
as NS in zones?
The goal was to have the primary use a particular TSIG key when it sends
out the NOTIFY messages to the secondaries, which is achieved by turning
off
The additional problem is that you also choose to hide the domain and the IP
addresses which doesn’t help others test stuff for you.
Why do you think named asked for the addresses of the servers? What does named
have and what does it need to send out notify messages? Is the server properly
c
On 18/04/2023 1:40 am, Jiaming Zhang wrote:
However, I got a question on the syntax of |also-notify|, what I can
see from bind9's user manual, the target of |also-notify| can be
| | [ port ] |
[ port ]|, does this means that I can use domain names of
the server instead of IP? Both name
Le 17/04/2023 à 20:40, Petr Menšík a écrit :
Ondřej,
it would be awesome if we could choose a higher quality release
instead to use for our longer support. But we lack any good metric to
choose one. So we update from time to time unless there is something
stopping us.
How could you e
Ondřej,
it would be awesome if we could choose a higher quality release instead
to use for our longer support. But we lack any good metric to choose
one. So we update from time to time unless there is something stopping us.
On 4/17/23 14:49, Ondřej Surý wrote:
Petr,
while I understand that
Hello Ondřej,
On Mon, Apr 17, 2023 at 9:26 AM Ondřej Surý wrote:
>
> > On 17. 4. 2023, at 15:59, Matt Zagrabelny via bind-users <
> bind-users@lists.isc.org> wrote:
> >
> > Greetings bind-users,
> >
> > I'm running a little older Debian bind:
> >
> > bind9 1:9.9.5.dfsg-9
>
> A litt
You do not have to sift through lists. We provide quite detailed git
branch with each change we make. It has references to bugs related too.
I admit changes listed in release notes of bind9 releases are nicer. But
we do not hide what and why we do changes, publish them quite nice way
for c9s [1
Hi Jiaming.
The arguments to "also-notify {...};" are explicit IP addresses.
Why do you need it? Do you have some secondaries that are not listed as NS
in zones?
Regarding views. Why would you have the same zone in an internal and
external view? A few years ago, having to maintain multiple zones
On Mon, Apr 17, 2023 at 9:04 AM Marco wrote:
> Am 17.04.2023 um 08:59:29 Uhr schrieb Matt Zagrabelny via bind-users:
>
> > I'm running a little older Debian bind:
> >
> > bind9 1:9.9.5.dfsg-9
>
> The upgrade your OS, stretch already has 9.10 and that is very old.
>
Agreed! It is on
> On 17. 4. 2023, at 15:59, Matt Zagrabelny via bind-users
> wrote:
>
> Greetings bind-users,
>
> I'm running a little older Debian bind:
>
> bind9 1:9.9.5.dfsg-9
A little older?
Debian Jessie reached EOL in June 2018, Debian Jessie LTS reached EOL in June
2020
So, you are r
Am 17.04.2023 um 08:59:29 Uhr schrieb Matt Zagrabelny via bind-users:
> I'm running a little older Debian bind:
>
> bind9 1:9.9.5.dfsg-9
The upgrade your OS, stretch already has 9.10 and that is very old.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe fr
Greetings bind-users,
I'm running a little older Debian bind:
bind9 1:9.9.5.dfsg-9
Scenario: I have two authoritative servers locally and three authoritative
servers that are part of the parent domain:
$ dig +short NS sub.example.com | sort
ns-0.sub.example.com.
ns-1.sub.example.c
Dear Nick,
Thanks for the reply. What was already set that I didn't include in my first
mail was that both views on both servers have match-clients set (for internal
set to "localhost" and "localnets", and for external set to "any"), so I'll add
the keys also to the match-clients.
However, I
Hi Andrej,
While I am not 100% sure on your use case, let me at least respond to this:
> But I’m starting to realize that I had misunderstood and
> overcomplicated things; simply referencing the "standard" policy again
> from equivalent zones in different views should (?) magically work (as
> Ni
> Our CentOS/RHEL 8 package are not just random BIND 9 snapshot.
Then please let me suggest that there is possibly an issue with
identification (customer said "9.16.23") and documentation of the
actual changes that are incorprorated in your distribution, compared
to the upstream-maintained patch r
Petr,
while I understand that you are trying to do a great job maintaining
the BIND 9 packages for RHEL, it is what it is - a random snapshot
defined not by the quality of the chosen version but by the time
availability. This is made even more complicated by applying a set
of patches where the set
If you have enabled SELinux and the package uses selinux policy to
restrict file access of named, I think named-chroot is not necessary. It
just complicates the usage and maintenance. But I think packages of ISC
do not have similar SELinux protection as Red Hat supported bind or
bind9.16 packag
Our CentOS/RHEL 8 package are not just random BIND 9 snapshot. If he
wanted bleeding edge, he would use RHEL 9 or even Fedora. But he uses
conservative package I am looking after. While it may have some known
issues, it has all important fixes it needs. Can you please stop telling
people to not
Hello. I just want to say everything seems to be working on my domain, and my
primary dns server already performs validation
Dnssec-validation is set to auto, like on the secondary dns, and it's working.
When I perform
Dig @dns www.dnssec-failed.org it already returns SERVFAIL and the rest seems
Hi Matthijs,
Thanks for your response.
dnssec-policy "ReuseKeysFromTheMainView" {
keys {
ksk key-directory lifetime unlimited algorithm ecdsap384sha384;
zsk key-directory lifetime unlimited algorithm ;
};
nsec3param s
Hi Jiaming.
You'll also need "match-clients" in the first view (at least), so that
the correct view handles the zone transfer request. As well as
specifying 'the right key' in match-clients, you'll probably also want
to specify 'not the wrong key', otherwise you won't be able to query the
vie
On 17/04/23 09:08, Andrej Podzimek via bind-users wrote:
The easiest (?) way to make DNSSEC work in all views has been to keep
a dnssec-policy for zones in *one* of the views (to generate and
maintain keys) and then passively refer to the keys from the zones’
counterparts in other views using a
You use keys as well when sending notify to select which view processes the
notify
> On 17 Apr 2023, at 18:44, Jiaming Zhang wrote:
>
> Dear community,
>
> I was wondering if notifying and updating zones in different view (say
> "internal" and "external") between bind servers via different ke
Hello Andrej,
On 4/16/23 23:08, Andrej Podzimek via bind-users wrote:
Hi bind-users,
I have asked this question on GitLab, but hijacking a closed issue to
ask questions is bad practice (often rewarded with silence), so I’m
re-posting the question here.
https://gitlab.isc.org/isc-projects/bin
Dear community,
I was wondering if notifying and updating zones in different view (say
"internal" and "external") between bind servers via different key is a good
practice. I got a sample zone/config like below:
```
view "internal" {
zone "example.com" IN {
# some other config, master zone
26 matches
Mail list logo
